Skip to content
This repository has been archived by the owner on Jun 30, 2022. It is now read-only.

Separate adapter-specific data in Redis #148

Open
ghost opened this issue Oct 25, 2015 · 1 comment
Open

Separate adapter-specific data in Redis #148

ghost opened this issue Oct 25, 2015 · 1 comment

Comments

@ghost
Copy link

ghost commented Oct 25, 2015

I want to use single Redis database with multiple instances of Lita because I want to share data between different chat services. Now Lita stores adapter-specific data (for example, user id) in single namespace. HipChat user with id 1 will overwrite user data of FancyChat user with id 1 in Redis field with key lita:users:id:1. The same can be said about rooms (and maybe something other, I don't know).

Can each of Redis namespaces users and rooms be separated into multiple namespaces with the suffix of adapter name, fox example: lita:users:id:hipchat:1, lita:users:name:hipchat:braiden-vasco? In this case each ID will be prefixed with adapter name, so no changes in other modules are required. Because Lita doesn't guarantee anything regarding Redis database scheme, this change doesn't break backward compatibility (interface of classes Lita::User and Lita::Room will not be changeg), so it can be implemented in minor release. No need to wait for Lita 5.

Or maybe some other key scheme may be used?

@jimmycuadra
Copy link
Collaborator

Although I don't encourage using the same Redis instance for multiple adapters/Lita instances, I do think the adapter data should be namespaced. The main use case I see is if the user decides to move from one chat service to another. They should be able to switch and keep their handler data without having to muck around with Redis directly.

This would need to wait for Lita 5, however, because it needs a deprecation plan for the non-namespaced adapter data and a way to migrate it to the new namespaces.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

1 participant