| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| | |
|
| |
|
|
|
| |
Looks like clients/hash behaves incorrectly when dead server comes back alive - it's never removed from dead_clients and thus retried indefinitely.
Failing test and fix are visible in 35ee9de, rest of PR simply adds some test coverage and refactors existing code a little.
|
| |\
| |
| | |
Prepare the version 3.0.1 release
|
| |/ |
|
| |
|
|
|
|
|
|
| |
Our current MockMemcacheClient doesn't throw an error if a key has a
space, and given MockMemcacheClient can be consumed by downstream
things, we want it to act as close to the real client as possible.
Rename _check_key to check_key_helper so we aren't importing a private
function.
|
| |
|
| |
pass the encoding from the hashed client to the pooled client when use_pooling is True.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
This code is in good shape for our next major release so this just
updates the changelog and package version.
|
| |\
| |
| | |
Add touch method to HashClient
|
| | | |
|
| |/ |
|
| |
|
|
| |
So that MockMemcacheClient is more complete and can be used for testing
prepend and append cases.
|
| | |
|
| |
|
|
|
|
| |
I was reading through the documentation and noticed a minor
inconsistency in the naming of the python-memcached library. This
commit updates the library name to reflect the real library we're
referencing.
|
| |
|
|
|
| |
For add(), replace(), cas(), and delete(), if noreply is True (or if it
is unset and self.default_noreply is True), the return value is always
True.
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
GitHub Actions profiles a nicer alternate to Travis for running
continuous integration jobs.
One compromise I've made in this migration is moving away from
using `tox` to run tests in our CI environment. We were previously
relying on the tox-travis to bridge between Travis' build matrix
and tox's environment list. At the moment, there doesn't appear to
be an equivalent for GitHub actions. Once there is one, we can
consider switching to it so that local and CI uses the same test
runner.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
