Generalization for Key/Value based datastore templates

[Tobias Trelle]

Hi,

are there any plans to provide a more general access to NoSQL datastores than let's say by means of the RiakTemplate or GemfireTemplate?

I'd like to make the suggestion to introduce a common interface for at least key/value based datastores. Nearly every key/value based store provides basic methods for creation, reading and deleting entities that are identified by the key:

public interface KeyValueTemplate<K, V> {

    void put(K key, V value);

    V get(K key);

    void remove(K key);

}

The benefit would be a looser coupling from the client to a given datastore. The client will use only the interface to interact with the datastore:

@Autowired KeyValueTemplate template;

and only the Spring app context will have knowledge of the datastore impl and its configuration.

Any comments are welcome.

Cheers,
Tobias

[Mark Pollack]

Hi,

Yes indeed but we have purposely tried to avoid putting in a "premature" abstraction. I think we can now take a look at that now and see what make sense. I've created a JIRA issue to track and discuss.

In the meantime, Gemfire already supports java.util.Map out of the box and there is a Redis backed implementation as well in the M1. Are you using Riak?

Mark

[Tobias Trelle]

Dear Mark,

I investigated the vFabric platform and was wondering why there is a strict separation between the API (spring-amqp) and the implementation (spring-rabbitmq) with the messaging solution RabbitMQ but not for the GemFire datastore.

My first sketch of a CRUD reference architecture looked like this:


As I understand now, at this point of time some service or adapter in that architecture would directly use a GemfireTemplate without further abstraction. Is that right?

Cheers,
Tobias