Will LIST, SET, HASH be supported?

[pcdinh]

Hi,

I have some practical cases that I implement using Redis with limited success due to lack of transaction support.

UC 1: Personal properties

User can track her own open sessions, recent reads or comments.

Basically, user can use many devices. Many of them are mobile ones. As a result she can never logs out explicitly. However, it is practical to provide her with ability to manage (view, delete) open sessions, devices in use. To do it, a batch of operations is required.

1.1 Multiple keys to store each session separately (key: value)

<session-key-1>: <user-id-1>,<device-name>,<seen-date>
<session-key-2>: <user-id-1>,<device-name>,<seen-date>
<session-key-3>: <user-id-1>,<device-name>,<seen-date>
...

1.2 Mapping between and related user information (key: hash)

<user-id>: HASH (username, permission, team-id, email-address)

1.3 Mapping between and active sessions (key: list)

<session:user-id>: LIST [session-key-1, session-key-2, session-key-3]

As you can see, if user decides to remove all active sessions, the following keys must be deleted in a transaction or she will end up with inconsistent data (some are deleted, some are not). It is obvious that LIST here can be changed with a serialized string. But in some other cases, concurrent access to session:user-id can be a concern.

UC 2: Team management

User can be invited to many team at the same time. Because invitations can be sent multiple times concurrently, they should be stored in a SET

<invites:user-id-1>: SET(<invite-id-1>, <invite-id-2>, ....)

The details of the invites can be stored in KEY:VALUE

<invite-id-1>: <details-as-string>

Again, a batch of operations is required: set or delete.

Other similar use cases: TO-DO list, bookmarking app, favorites, video or music channels ...

In my Redis implementation, some actions against a single key can be timed out (because of lack of resources or something). As a result, the batch of ops is done prematurely, making inconsistent data.

Transaction support for simple key:value model is great. But I think that without LIST, SET/ORDEREDSET, HASH support, business critical apps will end up with lots of patchy code to overcome the limit of underlying data store

Thanks

Dinh

[dumblob]

Transaction support for simple key:value model is great. But I think that without LIST, SET/ORDEREDSET, HASH support, business critical apps will end up with lots of patchy code to overcome the limit of underlying data store

I actually have quite an opposite opinion 😉. From my experience it's more difficult to map business critical framework/language abstractions to the underlying DB-specific types (especially lists, sets, trees, etc.) than simply having a transactional key value store allowing very easy and fast implementation of all the concrete framework/language abstractions.

The only use case for DB-level lists, sets, trees, etc. is in case you are actually building either your own shiny new framework and want to constraint yourself to just this one DB or if you're building an utterly simple application which doesn't need any such abstractions and can afford being specific DB dependent.