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

Mark Wolfe mark at wolfe.id.au
Fri Mar 18 19:11:26 EDT 2011


Thanks for the run down on projects you have been working on.

I am very interested in your suggestion around the rest template code, I
will have a look over this as it is an area I am very interested in. I also
concur that using something like the apache http client for REST is
overkill, hence why I have been using Netty, for those not aware is more of
a protocol agnostic NIO (New IO which is the Java way of using native APIs
such as Linux epoll event notification facility) based network library.

The JPA features are also very interesting and not dissimilar to the way
ripple enables a rails developer to get up and running quickly. In my view
it makes riak a more compelling solution for entry level developers who are
just looking for a good solid distributed database to put there stuff in.

Well that said I will be reading your code, which is of course the beauty of
open source. I plan to give that REST template a thorough test and review.

I found this blog post on the REST template:

http://blog.springsource.com/2009/03/27/rest-in-spring-3-resttemplate/

For those of you who are interested this source spring is available at the
following URL, note the rest template is in the web subproject:

https://src.springframework.org/svn/spring-framework/trunk/

And just for completeness here is a link to the spring data mapping code on
github.

https://github.com/SpringSource/spring-data-mapping

Thanks again for your responses, I think is great for all involved.

On Sat, Mar 19, 2011 at 12:14 AM, Jon Brisbin <jon at jbrisbin.com> wrote:

> 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
>
>
>
>


-- 
Regards,

Mark Wolfe

--
I am not young enough to know everything.
--
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.basho.com/pipermail/riak-users_lists.basho.com/attachments/20110319/60e5820f/attachment.html>


More information about the riak-users mailing list