abstracted vs. opinionated, object mapping (was: Re: Riak Recap for March 14 - 15)

Jon Brisbin jon at jbrisbin.com
Fri Mar 18 09:14:12 EDT 2011


As an aside: I'm wrapping up support for Grails GORM-style object mapping in the MongoDB Spring Data Document support. We haven't decided how to apply that mapping strategy to other NoSQL stores yet, but I suspect it'll only be a matter of a month or two before I can get full mapping support in the Riak Spring Data stuff.

It allows you to map entities al la JPA:

@Persistent
class Person {
  @Id
  private Integer ssn;
  @Reference // <- Externally-managed by using links, dbrefs, whatever
  private List<Child> children;
}

There's a metadata model that's responsible for reading annotations and configuring the mapper to know how to marshall/unmarshall entities and what to do with externally-stored relationships (in the case of MongoDB, we use DBRefs). It also supports autowiring and bean post processors, so you can inject resources into your entities:

@Persistent
class Person {
  ...
  @Autowired
  private DatastoreTemplate template;
}


It will be an interesting addition to the Riak support to have this same level of rich mapping, IMHO.

But on to the previous discussion...


On Mar 17, 2011, at 4:51 PM, Mark Wolfe wrote:

> ...[snip] The other was the rather convincing pitch Justin Sheehy gave a few people while at a pub in Melbourne.

He has a tendency to do that. ;)

> As a frequent user of the spring framework I really appreciate the work your doing around this framework, and indeed spring-data is something I will use in the future, however being required to use the spring stack just get a project connecting to riak probably wouldn't be the best idea in my view.

The idea behind Spring Data isn't to get a new, non-Spring project using a NoSQL store by forcing them to pull in all of Spring just to connect to the database. The focus has always been on extending Spring applications into the NoSQL world in a very "Springy" way; to have first-class support of the datastore within the Spring framework, which we assume you're already using. :)

When debugging the Spring Data Riak support, I delved through the innards of RestTemplate (the core REST helper in Spring 3.0). It doesn't use any other HTTP library, but is actually a thin wrapper around the built-in Java IO. This means a library developer could go to the Spring Framework project, download the source code for RestTemplate, shamelessly copy it (removing references to Spring classes, of course, and replacing them with your own, pure Java version) and create a thin abstraction over Java synchronous (or asynchronous) IO instead of relying on HTTPClient, which I personally don't like at all.

You'd obviously be duplicating what's already been done, of course. Things like the HttpMessageConverter in the RestTemplate are fantastic tools that a REST developer can use. Just the Jackson-based automatic conversion to/from application/json data is worth it in my mind. But it would be pure Java, with no external dependencies.


> I also think it is a good idea for the community as a whole to avoid an overly normalized driver approach while there is so much awesome stuff going on in the NoSQL and indeed riak space. A client which showcases this stuff is a much better approach, albeit a duplicate in many ways of other efforts. 

One of the discussions we have frequently is how to balance abstraction (to make a library easy to adapt to other NoSQL stores, given they all have roughly equivalent high-level functionality--by that I mean they all do CRUD, at the very least) versus exposing the benefits of that particular datastore. We're not interested in "hiding" the functionality that makes that datastore unique or valuable. The only question is how to expose it in a way that doesn't force you to duplicate your efforts when you go to do the same thing for The Other Guy's Database. :) 

If you write a driver for a specific database and don't have any plans to do the same thing for anyone else, you have the advantage of being fully opinionated and can be as low-level as you want. Unfortunately, we don't have that option so we have to find a balance somewhere. I know I sometimes personally get over-zealous in wanting to apply techniques I like to as broad a swath of the space as possible. That does mean you take a little "Riak-ness" or "MongoDB-ness" out of it as a side-effect of the process. I don't think that's inherently a bad thing, as long as you're careful about what you smooth over and that you don't take away a value proposition of the underlying datastore because The Other Guy's Database doesn't support it.


> This is of course just my two cents on the subject.

Appreciated and valuable! :)


Thanks!

Jon Brisbin

http://jbrisbin.com
Twitter: @j_brisbin



> 
> And lastly Abhishek I was writing an addendum to my ideas last night that included just that idea, like other projects why would you install a load balancer in front of a development cluster when you can make a simple load balancer in the client. This is quite common in a lot of messaging clients like apache activemq and hornetq ect.
> 
> Caveats to this is:
> a) You would probably stick to simple algorithms as this can get complex fast.
> b) Probably best only for a single or small pool of clients as your would be replicating the work of load balancing on every node.
> 
> This said I do agree it would be handy.
> 
> So something like:
> 
> riakClient.addHost("1.1.1.1", 8089)
> riakClient.addHost("1.1.1.2", 8089)
> riakClient.addHost("1.1.1.3", 8089)
> 
> Start making calls.
>  
> Time permitting I will hopefully add some of these to my own experimental client to try out some of these ideas  And after some consideration I agree it would be unwise to wholesale change the riak client at this stage. The work Russel has started is awesome and will make it easier in the future to recognize the impact if and when some underlying changes are made.
> 
> Anyway I have gone and written another war and peace on the subject and hopefully not the last one.
> 
> On Fri, Mar 18, 2011 at 12:57 AM, Abhishek Kona <abhishek.kona at gmail.com> wrote:
> Yes.
> Earlier query : http://lists.basho.com/pipermail/riak-users_lists.basho.com/2011-March/003461.html
> 
> -Abhishek Kona
> 
> 
> On 17/03/11 7:17 PM, Russell Brown wrote:
> I'm sorry but I don't understand, do you want the client to load balance across a Riak cluster rather than just speak to one node?
> 
> 
> _______________________________________________
> riak-users mailing list
> riak-users at lists.basho.com
> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
> 
> 
> 
> -- 
> Regards,
> 
> Mark Wolfe
> 
> --
> I am not young enough to know everything.
> --
> _______________________________________________
> riak-users mailing list
> riak-users at lists.basho.com
> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.basho.com/pipermail/riak-users_lists.basho.com/attachments/20110318/5dcf96c6/attachment.html>


More information about the riak-users mailing list