GORM for Redis Interview
JAXenter speaks with Grails project lead Graeme Rocher on the new GORM for Redis project.
As Head of Grails Development for SpringSource, Graeme Rocher is the project lead and co-founder of the Grails web application framework. He’s a member of the JSR-241 Expert Group which standardizes the Groovy language. Graeme authored the Definitive Guide to Grails for Apress and is a frequent speaker at JavaOne, JavaPolis, NoFluffJustStuff, JAOO, the Sun TechDays and more. Graeme joined SpringSource in late 2008 upon the acquisition of G2One Inc. Before founding G2One, Graeme was the CTO of SkillsMatter, a skills transfer company specializing in open source technology and agile software development, where Graeme was in charge of the company’s courseware development strategy and general technical direction.
After the 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 stores…..
JAXenter: What does Redis bring to the Grails community?
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 caching.
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 Cassandra.
There are however many stores out there and to get GORM support into the hands of developers will require collaboration with the NoSQL community.
JAXenter: What new features are planned, for upcoming releases?
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 milestone releases.