RC 3 - Bump Redis, Drop 3.7

• Bump redis & fakeredis to latest by @ChrisLovering in #21
• The latest major version of redis removes support for Python 3.7, which is also done here

Full Changelog: v1.0.0-rc2...v1.0.0-rc3

Redis-py

This release switches from aioredis v2 to redis-py. If you've made the migration to the first release candidate, there shouldn't be much that needs changing. The required changes are listed below. Since aioredis is mostly a subset of redis-py in version 2, you can start using more features after this release.

Added

• RedisSession.connect can take an optional ping flag which specifies if the services should be validated with a PING
• RedisSession.connect returns it's self so it can be better chained when creating the client
• RedisSession.pool was added back after being removed in the previous release candidate

Changed

• Switch aioredis for redis ~= 4.2.0
• RedisSession no longer takes a URL, but accepts all parameters which can be passed to redis.asyncio.Redis
• RedisSessionNotConnected is more explicit about the issue being a lack of calling the connect method, as opposed to actually being connected.
• RedisSession.connected has been renamed to RedisSession.valid
• RedisCache.delete returns the number of deleted entries

Deprecated

• RedisSession.pool has been deprecated due to being an unnecessary wrapper around RedisSession.client.connection_pool. For most cases, you should perform the operations directly from the client, and it'll manage all the pooling overhead. If you truly need to access the pool directly, you can do so through the client.

Full Changelog: v1.0.0-rc1...v1.0.0-rc2

Version 1.0.0 & aioredis 2.0

This version brings support for aioredis 2.0, which is a very large rewrite and breaking change for most projects. This library has changed a bit when it comes to interaction with aioredis, but the API remains mostly the same. Refer to the migration guide below for help on updating your project.

Removed:

• Connection Pool pattern. aioredis v2 has simiplied a lot of the logic revolving around connections, and it has become very difficult to manage it on a low level. You now only need to use whatever methods you want directly, without worrying about managing the connection pool.
• RedisSession.pool
• RedisSession.close & RedisSession.closed (closing sessions is mostly no longer a thing)
• RedisSessionClosed exception (same reason as above)
• Namespace locking (as per deprecation timeline) which includes: namespace_lock, namespace_lock_no_warn and NamespaceLock

Changed:

• RedisSession now takes a mandatory URL parameter. See aioredis.Redis.from_url
• Operations should now be performed on RedisObject.redis_session.client, which now validates namespace as well
• RedisTask now takes a RedisTaskQueue instead of just a RedisQueue.

Added

• RedisSessionNotConnected exception
• RedisSession.connected (can act as a general replacement for closed, since a session will never be closed once created)
• Marked support for python 3.10

Migrating

To migrate from 0.2 to 1.0.0, you need to do the following:

1. Add the URL parameter when initializing the session. Refer to aioredis.Redis.from_url
2. Remove all usages of namespace locking if they still exist
3. Implement the changes listed in the above sections. The list is comprehensive and can be used as a checklist.
4. If you use aioredis directly, follow the migration guide here. Unfortunately, the guide is incomplete. If you are using a static analysis tool, that should help you identify incorrect calls after the update. Here is an (incomplete) list of undocumented API changes which you might find useful:
   • brpoplpush and rpoplpush no longer take sourcekey and destkey, but src and dst
   • hmset_dict has been removed. You can use hset (or hmset, but that's deprecated) with the mapping kwarg instead
   • Exceptions have been rewritten, but are lacking in documentation.
   • Make sure to specify return type encoding on your redis session if you don’t want bytes returned. This only applies to using the client directly, this library’s types have not changed.

If you encounter other undocumented changes, please report them here and upstream. Changes will be added to this changelog.

Full Changelog: v0.2.0...v1.0.0rc1

A new datatype, a few improvements, and one deprecation warning

With the introduction of the RedisTaskQueue, this is another important step towards version 1.0.0. This release also includes various improvements and introduces the deprecation of the NamespaceLock.

New in this version

1. You can now set an expiry on a namespace

Starting with this version, you can set an expiry on an entire namespace. This means that when the expiry is reached, the value you get back is None instead of the value you had stored previously. The expiry is managed by Redis and has a precision of about 1 ms.

You can set the expiry in two flavours:

1. cache.set_expiry(seconds: float) sets an expiry seconds in the future. The highest precision is in ms; if you provide more decimal places, they will be truncated.
2. cache.set_expiry_at(timestamp: float | datetime.datetime) sets an expiry at the specified timestamp. If you provide a timestamp in seconds, it will be interpreted at seconds since the Unix Epoch (max. precision: 1 ms; actual resolution depends on the platform running Redis). You can also provide a datetime.datetime instance, which will be converted into a Unix timestamp. The general recommendation for datetime.datetime objects is to use one that is timezone aware or a naive instance in a timezone matching the timezone settings of the current machine.

2. Compound operations are now atomic from a Redis perspective

Some operations, like RedisCache.pop, require the execution of multiple Redis commands. As this creates sensitivity to race conditions, namespaces were locked to a single operation at a time. However, this still meant that race conditions could exist in a multi-client setup. This is obviously not ideal.

To prevent those kind of race conditions, compound actions are now executed as a Redis Lua script. This means that their execution is atomic within Redis itself, eliminating potential race conditions between clients.

Another advantage is that the namespace_lock decorator was susceptible to introducing deadlock conditions: If one locked method called another method that required the same lock, the namespace would be locked "forever". Using the new scripting approach, such a lock is no longer necessary.

3. Consume Queue items using asynchronous iteration

The RedisCache class now supports asynchronous iteration. By default, a async for task in queue will consume all tasks in the queue before stopping. Alternatively, the iter_tasks methods can be used to start an iteration that waits for new tasks to become available, optionally waiting only for the set timeout.

4. New datatype: RedisTaskQueue

A RedisTaskQueue is very similar to a TaskQueue except that instead of consuming elements from the queue directly, it tracks tasks until they're completed. The way this works is that tasks are moved to a "pending" queue from which they are only removed when a task is marked as done.

To make working with this new tasks easier, they are wrapped in a RedisTask instance, with methods to finalize (mark as done) and reschedule (move back to the main queue) the task, if needed.

In general, clients should reschedule all tasks in the "pending" queue at start up using the reschedule_all_client_tasks method to clean up lingering tasks from the previous client application run.

To support a multi-client setup, each client can set a unique ID, meaning that they will get their own, unique "pending" queue. Do make sure that client IDs persist through restarts of the client, otherwise the previous "pending" queue would become inaccessible.

Deprecation of NamespaceLock

Related to making RedisCache operations atomic, the NamespaceLock has been deprecated and will be removed in version 1.0.0. While the NamespaceLock class and namespace_lock decorator will continue to function until version 1.0.0, using them is discouraged, as it's easy to get into a deadlock situation.

If you're running a single-client setup and want to make two of your own functions/methods atomic/mutually exclusive, consider using the RedisObject.atomic_transaction decorator, which available on all Redis types.

Release version 0.1.4

The previous release did not include all subpackages in the build. This release should contain everything that's necessary to run the package.

Release version 0.1.3

A small patch release that fixes an issue with using the password kwarg while using fakeredis. The server back-end provided by fakeredis does not support the Redis AUTH command, which triggers an exception whenever password is set to anything but None. To prevent that bug, we now just drop the password kwarg whenever constructing a pool using fakeredis instead of aioredis.

Release version 0.1.2

This new patch update only touches upon the way we package the code.

Changes:

• The dev additional feature option has been dropped in favour of using pipenv to set up a dev environment
• Python 3.7 has now been specified as the minimal Python version
• The tests/ directory is no longer included as a separate package in our PyPI package
• The website url on PyPI now points to this repository

Release version 0.1.1

This is the first production-ready release of this package. It should be fully functional and ready to use.

Changes compared to v0.1.0-alpha:

• The newly introduced NamespaceLock ensures that compound operations, like RedisCache.pop, should be atomic within a namespace. No other operations should be able to run while another operation within that namespace is being executed.
• The check for duplicate namespaces has been removed, as linking two instances to the same namespace could be intentional.
• All Redis types are now able to "bypass" the global application namespace. This allows an instance to connect to a namespace set by another application (e.g., in a producer/consumer queue scenario).

Release Version 0.1.0-alpha

This is the first alpha release of async-rediscache. It should implement the basic functionality, although the API is still open to breaking changes until the first version is released.

Dev Release: Testing GitHub Actions Publication Pipeline

v0.0.1-dev6

Bump version to 0.0.1-dev6