GORM for Redis Interview
JAXenter speaks with Grails project lead Graeme Rocher on the new GORM for Redis project.
first milestone of GORM for Redis was released last week,
JAXenter asked Grails project lead Graeme Rocher a few questions on
this new project, and how it might relate to additional NoSQL
JAXenter: What does Redis bring to the Grails
Graeme Rocher: Redis is a key/value store which
supports extremely fast read operations so it’s useful in a number
of situations where caching solutions have been used, however since
Redis supports complex data types like sets, lists and hashes you
can also do some more advanced querying compared to other key/value
stores. This makes it appropriate for a range of scenarios from
sorting data, calculating statistics, queueing jobs or just basic
As an example Redis’ set type allows you to store a unique set
of values and easily return random entries or pop (remove) entries
from a set. Implementing this type of functionality in a performant
way on a relational database is typically much harder.
JAXenter: What is GORM for Redis?
Graeme Rocher: GORM for Redis allows Grails
developers familiar with the programming model used to interact
with relational databases to use the same programming model with
Redis in a performant way.
A Grails application’s domain model can be persisted to both a
relational store and Redis transparently. Querying is also
transparent as GORM for Redis will automatically build the
appropriate Redis indices for you.
There is also a low-level API so that the basic Redis commands
can be used, thus giving the user the benefit of a higher level
abstraction and more direct access to Redis.
JAXenter: At the project announcement,
SpringSource suggest a collaboration with the NoSQL community to
build out similar support as that found in GORM for Redis. What
form do you envision this support taking?
Graeme Rocher: There are a diverse range of
stores out there all of which have their own unique API.
Transparent persistence to these stores via GORM would benefit
adoption of these stores as it would provide developers with the
tools needed to be productive. Of course there is a balance as it
is equally important to have access to the lower level APIs to get
the most out of the underlying datastore.
Redis for GORM is a great example of how this balance is
achieved with both a higher level abstraction and access to the
low-level plumbing. We believe the same can be achieved for other
NoSQL stores and have prototyped an implementation for
There are however many stores out there and to get GORM support
into the hands of developers will require collaboration with the
JAXenter: What new features are planned, for
Graeme Rocher: There are some features not
implemented yet such as optimistic locking, nested criteria queries
and dirty checking that will be implemented over the course of the