Dogpile.cache

Latest version: v1.3.3

Safety actively analyzes 630523 Python packages for vulnerabilities to keep your Python projects secure.

Scan your dependencies

Page 4 of 9

1.0.0

Released: Sun Jul 19 2020
feature


- **[feature]** Improved plugin scanner performance by switching from pkg_resources
to stevedore.

- **[feature] [redis]** Added support for Redis Sentinel. Pull request courtesy Stéphane Brunner.
See `RedisSentinelBackend`.

References: [181](https://github.com/sqlalchemy/dogpile.cache/issues/181)

misc


- **[change: py3k]** For version 1.0.0, dogpile.cache now supports Python 3.5 and above
only.


rel_0_9_2

0.9.2

Released: Mon May 4 2020
bug


- **[bug] [installation]** Ensured that the "pyproject.toml" file is not included in builds, as the
presence of this file indicates to pip that a pep-517 installation process
should be used. As this mode of operation appears to be not well supported
by current tools / distros, these problems are avoided within the scope of
dogpile.cache installation by omitting the file.

References: [178](https://github.com/sqlalchemy/dogpile.cache/issues/178)


rel_0_9_1

0.9.1

Released: Wed Apr 29 2020
bug


- **[bug] [tests]** Added `decorator` module as a required testing dependency to
`tox.ini` so that tests work when this is not pre-installed.

- **[bug] [redis]** Added option to the Redis backend
`RedisBackend.thread_local_lock`, which when set to False will
disable the use of a threading local by the `redis` module in its
distributed lock service, which is known to interfere with the lock's
behavior when used in an "async" use case, within dogpile this would be
when using the `CacheRegion.async_creation_runner` feature. The
default is conservatively being left at True, but it's likely this should
be set to False in all cases, so a warning is emitted if this flag is not
set to False in conjunction with the distributed lock. Added an optional
argument to `RedisBackend` that specifies whether or not a
thread-local Redis lock should be used. This is the default, but it breaks
asynchronous runner compatibility.

References: [171](https://github.com/sqlalchemy/dogpile.cache/issues/171)


rel_0_9_0

0.9.0

Released: Mon Oct 28 2019
feature


- **[feature]** Added logging facililities into `CacheRegion`, to indicate key
events such as cache keys missing or regeneration of values. As these can
be very high volume log messages, `logging.DEBUG` is used as the log
level for the events. Pull request courtesy Stéphane Brunner.


rel_0_8_0

0.8.0

no release date
- **[bug] [setup]** Removed the "python setup.py test" feature in favor of a straight run of
"tox". Per Pypa / pytest developers, "setup.py" commands are in general
headed towards deprecation in favor of tox. The tox.ini script has been
updated such that running "tox" with no arguments will perform a single run
of the test suite against the default installed Python interpreter.

References: [157](ticket:157)

- **[bug] [py3k]** Replaced the Python compatbility routines for `getfullargspec()` with a
fully vendored version from Python 3.3. Originally, Python was emitting
deprecation warnings for this function in Python 3.8 alphas. While this
change was reverted, it was observed that Python 3 implementations for
`getfullargspec()` are an order of magnitude slower as of the 3.4 series
where it was rewritten against `Signature`. While Python plans to
improve upon this situation, SQLAlchemy projects for now are using a simple
replacement to avoid any future issues.

References: [154](ticket:154)

- **[bug] [installation]** Pinned minimum version of Python decorator module at 4.0.0 (July, 2015) as
previous versions don't provide the API that dogpile is using.

References: [160](ticket:160)

- **[bug] [py3k]** Fixed the `sha1_mangle_key()` key mangler to coerce incoming Unicode
objects into bytes as is required by the Py3k version of this function.

References: [159](ticket:159)


rel_0_7_1

0.7.1

Released: Tue Dec 11 2018
- **[bug] [region]** Fixed regression in 0.7.0 caused by [136](ticket:136) where the assumed
arguments for the `CacheRegion.async_creation_runner` expanded to
include the new `CacheRegion.get_or_create.creator_args`
parameter, as it was not tested that the async runner would be implicitly
called with these arguments when the `CacheRegion.cache_on_arguments()`
decorator was used. The exact signature of `async_creation_runner` is
now restored to have the same arguments in all cases.

References: [139](ticket:139)


rel_0_7_0

Page 4 of 9

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.