Feature/radex stores - #36
Conversation
…Store Introduces radex.store (Store/Endpoint base + RedisStore/DragonStore) so RADEX can provision and tear down its own Redis or Dragon DDict backend instead of requiring callers to do it manually, with idempotent async lifecycle (start/ready/endpoints/shutdown), plus tests and examples.
Store and Endpoint now only launch backends and expose connection info (.endpoints/.serialize()) -- callers build the typed RADEX client (DragonClient/RedisClient) themselves from an endpoint, giving clean N-clients-per-endpoint / clients-across-M-endpoints support instead of Store guessing cardinality. RedisStore keeps a .client() convenience for a raw redis-py client only; DragonStore has no client() at all. Updated both examples and the affected tests to match.
| total_mem: int | None = None, | ||
| *, | ||
| working_set_size: int = 2, | ||
| wait_for_keys: bool = True, |
There was a problem hiding this comment.
I can see the point of letting devs set wait_for_keys (e.g. like we do in the unit tests). What about to make it double extra clear that you shouldn't do that put it as a _wait_for_keys?
There was a problem hiding this comment.
Also, probably super paranoid, but also check that wait_for_keys isn't set in extra_ddict_kwargs
| _DDict = None | ||
|
|
||
|
|
||
| _PROBE_KEY = "__radex_store_liveness_probe__" |
There was a problem hiding this comment.
That's a nice way to do the check. Could we breadcrumb somewhere a TODO to wire in some a more direct health check (at least for dragon)
| self._processes: dict[int, asyncio.subprocess.Process] = {} | ||
| self._planned: list[tuple[str, int]] = [] | ||
|
|
||
| def client(self, index: int = 0, **kwargs: Any) -> "redis.Redis": |
There was a problem hiding this comment.
I would prefer to use "our" radex client. From what I see it's only really being used in testing as a ping. Let's do this as a "probe" key.
| return f"{self.host}:{self.port}" | ||
|
|
||
|
|
||
| class RedisStore(Store): |
There was a problem hiding this comment.
I would prefer to leave this as single-node only for now (not N-independent instances). For SmartRedis users rotating onto this, I'd rather have them complain to us that they want clustered behaviour as opposed to being confused why their multi-node db doesn't have a global key space
2 participants
No description provided.