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.k...@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@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@lists.basho.com
> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
_______________________________________________
riak-users mailing list
riak-users@lists.basho.com
http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
