search

SebastiaanZ / async-rediscache

An easy-to-use asynchronous redis-backed caching utility
18 stars 3 forks source link

Migrate to redis 4.2.X+ #19

Closed ChrisLovering closed 2 years ago

ChrisLovering commented 2 years ago

As per the notice at the top of https://github.com/aio-libs/aioredis-py, aioredis is no longer maintained. The funcitonality has been migrated to https://github.com/redis/redis-py 4.2.X+, where it will be supported by redis themselves.

redis-py has the same async syntax as aioredis 2.X so after https://github.com/SebastiaanZ/async-rediscache/pull/18 imports could be changed to from redis import asyncio as aioredis and should just work.

HassanAbouelela commented 2 years ago

As the wise aioredis documentation states:

aioredis v2.0 is now a completely compliant asyncio-native implementation of redis-py. The entire core and public API has been re-written to follow redis-py‘s implementation as closely as possible. This means there are some major changes to the connection interface, but we now have an interface that is completely consistent across the two libraries

Following this information, I wrote #18 with a lot of - as the documentation put it - "connection interface" changes. It was a bulk of the diff. I wanted to work on this issue for the second release candidate hoping that version 1.0.0 would be released without requiring changes in the near future. The aioredis documentation claims that it should be a small one-to-one migration, and it claims to match redis-py implementation "as closely as possible". Apparently, that means picking a small, specific portion of it and implementing it.

When reviewing the redis-py documentation, I found that they support the old instantiation method which didn't use URLs, and they support client pools. Removing this stuff from the library is what a bulk of RC1 was, and it's going to be a bulk of what users downstream will need to change.

In the interest of making the migration as smooth as possible for users, I'm going to be extending the projected timeline for the next RC, and work on this migration. It might end up being similar in size to RC1, and mostly be reverting changes from there. I'm a little annoyed, but we'll just keep chugging along.

HassanAbouelela commented 2 years ago

I've started working on the migration, and I've figured out it's not as bad as I initially thought. While it's true that redis does expose the pool in a way that is very easy to work with unlike aioredis, it does seem like the client approach is still the cleanest and easiest. For this reason, I think my implementation will keep the client getter, and will use the client in the codebase (since it's cleaner for most operations), and I'll re-expose a pool getter with a deprication warning. This should hopefully ease the transition for end users, while still promoting best practices.