(Quick Reference)

3 Object Mapping - Reference Documentation

Authors: Jon Brisbin, Graeme Rocher

Version: 1.0.0.M4

3 Object Mapping

Object mapping works largely as described in the documentation on GORM. In general you can continue to model your associations using typical GORM notation such as hasMany, belongsTo and so on.

Here is an example of a domain class that can be persisted to Riak:

class Person {

String firstName String lastName

static constraints = { firstName blank:false lastName blank:false } }

Since Riak doesn't support the notion of saved indexes, there are no options to specify what columns to index for faster searches. The GORM support for Riak relies on Riak's Map/Reduce implementation for queries, criteria, dynamic finder methods, and so on. As such, searching for data in Riak using finder methods can be slower than on other NoSQL datastores given a very large dataset. Caveat emptor.

That said, finder methods are fully supported in Riak for GORM:


3.1 Dealing with Eventual Consistency

One of the important features of Riak is that, by default, Riak promises to be "eventually consistent" rather than synchronously up-to-date. This means that when an update to data in Riak is issued, the update method might return before the data has been fully written to disk. This increases performance of writes but means operations that depend on just-inserted data being available (for queries, for example) need to be careful about when they are run.

If you want a save() call to be guaranteed to have persisted the object to disk before returning to your application, then you need to pass a QOS (Quality of Service) parameter to the entity's save method. You use the same names for the parameters as you would if you were specifying them on an HTTP URL: w for write, dw for durable write, and r for read.

For example, to ensure that an object has been completely flushed to disk before returning, use the "durable write" parameter:

def p = new Person(firstName: "Bob")
p.save([dw: "all"])