update on Grails Neo4j GORM plugin

The milestone release 1.0.0.M2 of the  Neo4j Grails GORM plugin was published a couple of days ago. The plugin provides a GORM compliant implementation backed by a Neo4j datastore. This means you can switch any Grails application to use Neo4j by simply exchanging the GORM plugin used.

Plugin documentation can be found at There is also a very minimal demo application available at, see for the source code. The demo app consists of three trivial domain classes with scaffolding controllers – nothing more for now.

Since there is currently the Neo4j Challange in progress, I’ve decided to participate there. As already stated the neo4jsample demo application is very minimal but it its intention is to serve as a starting point for your own Grails application using Neo4j as datastore backend. If you want support this project in the neo4j challenge, please send a tweet.

19 replies on “update on Grails Neo4j GORM plugin”

When Grails has the Neo4j plugin installed, does that mean that the app would have both MySql and Neo4j accessible, or is it more a question of choosing Neo4j as the backend and sticking with it? I am exploring web frameworks that integrate/use Neo4j and Grails is a leading candidate, but before I test various installations, I wanted to get a few basic questions answered and have a better idea how the data would be modeled.



Is there a plan to do a release version of this plugin? Also can you point out where is the code hosted for this plugin as the link on grails plugin page seems to be broken.


Stefan –

Thanks for your work on this plugin. I’ve installed it for a project I’m working on and have experienced very poor performance. I’m wondering if there’s something wrong with my setup.

I’ve done some work with the grails-data-mapping project, and so I had the source code checked out for neo4j. While I was debugging it, it seemed that every object was loaded individually through the REST api (no batching retrieval of query data). Additionally, it seemed like every object was loaded twice. Once inside the Neo4JQuery (line 196), and the second time via the lazy loading mechanism. Is there any way to indicate that you want the results to be selected in a batch?

Is this how it should work? I’ve noticed that the auto-index for the __type__ field doesn’t seem to be working… maybe that’s it?


@Stefan Armbruster

Yeah, I figured as much and ended up switching to embedded mode. Things are performing better now, but still not great. I think I’m just realizing that some of the things I took for granted with RDBMs (paging through resultsets efficiently) just doesn’t exist with a graph database…

A question about the plugin – Did you ever consider creating the plugin as a Blueprints/Gremlin plugin, to allow other graph providers to be plugged in? Is there any inherent weakness in the Blueprint API that would prevent it from support the GORM semantics?

I’m at the point that I’d like to play around with Titan and OrientDB, but would rather not have to learn their native APIs.

Last question (to partly contradict my prior statement) – at any point, did you start to feel like GORM/Hibernate semantics just didn’t fit well with a graph database? You’ve stated here and elsewhere that a primary motivation was scaffolding… so, would you still recommend GORM/Neo4J for a project that’s more of a pure back-end? Or would you go with native neo4j or something like Blueprint?


the focus so far was on “being fully GORM” compliant, performance will come next. If you experience slow queries, you can always invoke Cypher queries directly.

I don’t have any plan to use Blueprint/Gremlin. Use a cross graphdb abstraction layer means to rely on the least common denominator. Compared with RDBMS, Graph DBs are to young that a commonly supported standard has already evolved. From my perspective I see Neo4j as clear market leader, and I’ll focus on this. (Side note: I’m employed at Neo Technology, so excuse a slightly biased opinion here).

GORM fits rather nicely to a graph db – for couple of applications I do not clearly see the benefit of a traditional domain model. The only really big advantage is IMHO the scaffolding support. For a lot of cases it makes sense to use the domain model for admin pages using scaffolding. For complex queries I have a strong preference to use the native querying capabilities, namely cypher.


@Stefan Armbruster

Any chance you can upgrade your plugin to be Neo4j 2.x compliant?


Hi Erik,
I’m currently busy with that and doing good progress. The GORM TCK is ~95% green right now. Next step is to integrate the mapping library in the plugin and care about environment config. Development is done at and will be merged to upstream repo when a “good enough” status is reached. We’ll see a dev snapshot/milestone release with the next weeks.

Perfect! Thank you for maintaining such an amazing plugin 🙂

One issue I noticed when I was working with the current version of the plugin, is that the Neo4j GORM has no knowledge of ArrayLists. I will work on replicating the error when I am not in the office and post a stacktrace.

Stephen – I am trying to figure out how to take advantage of the auto-indexing. I can’t seem to find any documentation on how to implement the indexing functionality.


Is there any way of creating “Schema” indexes when starting up a new neo4j embedded instance?

Erik, the currently release plugin is based on Neo4j 1.x, therefore we don’t support schema indexes. The new plugin version 2.0 fully supports schema indexes. Any domain class property having “index: true” in the mapping closure will have a schema index. A local snapshot already works nicely, I guess I’ll have a first milestone out of the door next week.

Leave a Reply

Your email address will not be published. Required fields are marked *