Announcement Announcement Module
Collapse
No announcement yet.
Generalization for Key/Value based datastore templates Page Title Module
Move Remove Collapse
X
Conversation Detail Module
Collapse
  • Filter
  • Time
  • Show
Clear All
new posts

  • Generalization for Key/Value based datastore templates

    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:

    Code:
    public interface KeyValueTemplate<K, V> {
    
        void put(K key, V value);
    
        V get(K key);
    
        void remove(K key);
    
    }
    http://dl.dropbox.com/u/10861720/Spr...bstraction.gif

    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:

    Code:
    @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
    Last edited by Tobias Trelle; Jan 12th, 2011, 02:40 AM.

  • #2
    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

    Comment


    • #3
      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:
      https://www.boxenterprise.net/shared/6lfe1ah8bb

      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

      Comment

      Working...
      X