UpdatableStore

[avibryant]

Sketching out an UpdatableStore trait as described in #113. Extends JMapStore and ConcurrentHashMapStore to be UpdateableStores, and adds a new RedisUpdatableStore that uses the TransactionalClient.

Totally untested so far.

Todo:

• add tests
• memcache support
• mysql support
• combinator to retry on failed updates
• ConvertedUpdatableStore
• ShardedUpdatableStore
• EnrichedUpdatableStore
• combinator to turn any UpdatableStore + a monoid into a MergeableStore

[softprops]

neat!

[johnynek]

is it too restrictive to return Future[Option[V]] which is the original input to the function? This way, the caller knows the value that was actually set into the store.

This does make buffering a pain, and I'm speculating on use cases, so ....

[avibryant]

I was mostly just going by analogy with put, which also returns Future[Unit].

Buffering being a pain is a good point, and for me right now that outweighs any hypothetical benefit of returning it (I know that we'd want buffering with this, I'm not sure what we'd use the return value for).

[sritchie]

The TODOs are so awesome! Hadn't seen that before.

[sritchie]

@avibryant, are you still interested in getting this bad dawg in? I think we can get it into the next release if so.

[avibryant]

I'm still interested but don't actively need it right now, so I'm in no rush. What do you think is the minimal TODO to make it worth merging?

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}