Async-rediscache

Latest version: v0.2.0

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

Scan your dependencies

Page 1 of 3

1.0.0rc2

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**: https://github.com/SebastiaanZ/async-rediscache/compare/v1.0.0-rc1...v1.0.0-rc2

1.0.0rc1

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](migrating) 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.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`](https://aioredis.readthedocs.io/en/v2.0.1/api/high-level/#aioredis.client.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`](https://aioredis.readthedocs.io/en/v2.0.1/api/high-level/#aioredis.client.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](https://aioredis.readthedocs.io/en/latest/migration/). 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.

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

**Full Changelog**: https://github.com/SebastiaanZ/async-rediscache/compare/v0.2.0...v1.0.0rc1

0.2.0

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.

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.

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`.

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

Page 1 of 3

© 2024 Safety CLI Cybersecurity Inc. All Rights Reserved.