| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For consideration for v3.0.0
'cas' is documented as needing to be an int or bytestring of the digits
0-9. However, this is not actually enforced and it is possible to pass a
value to pymemcache which doesn't conform to these rules. In fact, you
can do weird things like `cas=b'noreply'` and potentially trigger
"unexpected" behavior.
To go along with validating int inputs, validate cas inputs. However,
these are not necessarily integers. Instead, if an int or string is
given, it will be encoded as a bytestring. But in order to validate the
value given, it is checked against isdigit() .
(NB: You could also use `int(cas)` for very similar checking.)
Rationale for allowing non-integer inputs to cas is not obvious.
Presumably it allows callers using `gets()` to pass the `cas` value they
get back into a `cas` command without issue. But it may be debatable.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Change serialization interface to be an object
Rather than passing separate serialization and deserialization methods
to a pymemcache client, pass an object implementing a very simple
two-method interface.
This is a rather significant breaking change and should be part of an
x.0.0 major release.
Resolves #56
As suggested in that issue, this is a cleaner interface, as there's no
sensible context in which you would provide only one of these two
methods and it should therefore be thought of as a
serialization/deserialization protocol.
Also adds a note to the documentation's Best Practices list that you
should use the built-in serializer object unless you have a reason to do
otherwise.
* Support "de/serializer" in addition to "serde"
In order to support older client usage in addition to the new
serialization object (protocol), restore the "serializer" and
"deserializer" arguments to the Client classes.
These are marked as deprecated and will be automatically wrapped into a
small "serde" object.
In order to make the various object names more distinguishable and more
informative, the built-in default serializer is now called
"python_memcache_pickle_serde"
Additionally, default client.serde to a "no-op serializer".
This object does no transforms on the data. By putting this in place, we
can skip some conditionals in the code around presence or absence of a
serializer and therefore simplify internally (at the cost of an extra,
unnecessary, functional call in some cases).
It also simplifies logic around the handling of flags because we are now
*guaranteed* the presence of a serializer object which returns some
flags. i.e. "default flags" are no longer the responsibility of the
various serializer usage sites.
This is done carefully to ensure that passing a `serializer` without a
`deserializer` is respected.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If a caller tries to send
- a fractional expiration time
- a string for the "incr" command
- delay=None (instead of delay=0)
The pymemcache base client will now catch these usage mistakes a
throw a MemcacheIllegalInputError.
Although there are existing valid (but undocumented) usages of the
current string conversion behavior, the docs state that these values
are supposed to be ints. Now if a non-int value is used, it will
immediately trigger an error.
This behavior is superior to the prior behavior especially in the
case where a command is used with `noreply=True`. It can fail to
parse, but the client won't pick up on this until the next call to
memcache which reads the reply.
The especially bad case we're seeking to avoid is this:
from pymemcache.client.base import Client
client = Client(("localhost", 11211))
client.set("foo", "bar", expire=1.5, noreply=True)
client.get("foo") # triggers MemcacheUnknownCommandError
Applies to all commands using `expire`, `delay`, incr and decr
inputs, and memlimit.
Because this is can be a breaking change for some users, the changelog
entry is written under 3.0.0 (unreleased).
closes #240
|
| |
|
|
|
| |
When defining `long_description` in setup.cfg using the `file:`
directive, we need to keep everything on one line. Otherwise, it will
treat the value as a block of literal text.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We introduced the ability to override the serializer-returned flags
values in 26f7c1b1. Unfortunately, there was a flaw in that logic which
resulted in the first item's flags being used for all later items. This
bug primarily affected set_many()'s behavior when the data dictionary
contained multiple different value types which were assigned different
per-value flags values by the serializer.
For example:
set_many({'a': 'string', 'b': 10})
If a serializer returned different flags for strings (e.g. 1) and
integer values (e.g. 2), the previous logic would have set ``flags``
to 1 the first time through the loop and repeated that value for the
second item, instead of using 2.
This was the intended behavior when ``flags`` was explicitly passed to
set_many(), but not for the default case where we still want to respect
the flags values returned by the serializer.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a stylistic issue with little chance for actual impact. Some
methods use 'ascii' verbatim and some use `self.encoding` (which
defaults to 'ascii'). Those which are using `ascii` are only supposed to
be accepting integer inputs, so this is actually fine.
However, the result is a potentially confusing discrepancy -- why does
`Client.touch` use `ascii` while `Client.add` uses `self.encoding`?
To alleviate this potential confusion, be consistent about applying
`self.encoding` to all memcached commands in the base client.
This does not impact the `_check_key` func, which re-encodes potential
unicode inputs as ASCII.
|
| |
|
|
|
|
|
|
|
| |
resolves #239
Add a warning to the Best Practices section of the Getting Started
doc which explains the interaction between `noreply=True` and error
handling.
Also, fix a very minor typo, ``"noreply`` in a nearby line.
|
| | |
|
| |
|
| |
extract _extract_value() from _fetch_cmd() to support customized value extraction logic.
|
| |
|
| |
added flags in client functions to provide support for extra memcached operations.
|
| | |
|
| |
|
|
| |
Python 3.4 has reached end-of-life so remove it from the set of
officially supported Python versions.
|
| |\
| |
| | |
Update the changelog with recent changes
|
| |/ |
|
| |\
| |
| | |
Remove redundant '' from %r values
|
| | |
| |
| |
| | |
repr()'d strings (via %r) are already quoted.
|
| |\ \
| |/
|/| |
Improve ASCII encoding failure exception
|
| |/
|
|
|
|
| |
Memcache can only store binary-safe values. We raise an exception when
we're unable to encode a data value using the 'ascii' codec. Improve the
exception message to make the error case clearer.
|
| |\
| |
| | |
Add default_noreply paramter to HashClient
|
| |/
|
|
|
|
| |
This allows users to specify the noreply behavior upon creation
of a HashClient like they are already able to do for Client and
PooledClient.
|
| |\
| |
| | |
Handle unicode key values in MockMemcacheClient correctly
|
| |/
|
|
|
|
|
|
| |
The actual client tries to encode unicode and if it fails
MemcacheIllegalInputError is raised. Fix the MockMemcacheClient to do
the same thing.
Fix bug #222
|
| |\
| |
| | |
Introduce package metadata configuration by using setup.cfg
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Since setuptools 30.3.0 we can use setup.cfg to configure package
for build and distribute. These changes propose to adopt a more
modern approach to package pymemcache by using latest and stable
feature of setuptools.
Overview:
- remove python code to maintain
- introduce package metadata,
- centralize version management in package metadata
|
| |\ \
| |/
|/| |
Ignore the .eggs/ directory
|
| |/ |
|
| |\
| |
| | |
Mention django-pymemcache in the README
|
| |/ |
|
| |\
| |
| | |
Use '==' to compare strings
|
| |/ |
|
| |\
| |
| | |
Parse version directly from pymemcache/__init__.py
|
| |/
|
|
|
|
|
|
|
|
|
| |
We can no longer import the __version__ attribute because there is no an
implicit runtime dependency on six (as of #197), and we can't guarantee
that six is installed until *after* setup.py is parsed and run.
Instead, parse the `__version__ = 'x.y.z'` string from __init__.py to
extract the version.
Fixes #214
|
| |\
| |
| | |
Finish preparing the 2.1.0 release
|
| | |
| |
| |
| |
| | |
This updates the changelog and includes a final documentation cleanup
pass.
|
| |\ \
| |/
|/| |
Omit test/* code from the coverage report
|
| | | |
|
| |\ \
| | |
| | | |
Add support for the 'cache_memlimit' command
|
| | | | |
|
| | | | |
|
