Hi all,

Robert Rees gave Neo4j a shot last week, trying to drive it from
Groovy but came away disappointed:


I asked why:


And here is Robert's excellent reply. I asked permission to repost on
the list to get everyone's input and kept Robert in cc since he's not

See mail below.


---------- Forwarded message ----------
From: Robert Rees <[EMAIL PROTECTED]>
Date: Fri, Nov 28, 2008 at 4:04 PM
Subject: Starting pain with Neo4j

Hi Emil,

This is a follow up to the Tweets we've exchanged. I might also blog
about this at some point, for my own reference.

So what was the pain with getting started with Neo4j?

Well first I found I couldn't run it without the Shell and JTA jars. I
wouldn't mind but the documentation implied that if you just want to
embed a graph db and go you only need the main jar. I think in terms
of distributables if Neo4J requires these things then it is worth
having a "complete" jar for when you do want to just get going and
play around with it.

The EmbeddedNeo name also caused me a lot of confusion. I read that as
being "in-memory" in the style of Hsql or Derby. I didn't understand
that the path I was passing had to be a real directory rather than a
virtual or conceptual path. I then felt that if the process was going
to create a lot of files and be quite fussy as to whether it was
explicitly asked to shutdown then it would actually be easier to have
it run as a server process. The Abstract Server classes and the whole
process felt like I had all the process of a big server architecture
with all the micromanagement involved but none of the power of being
able to connect and share multiple clients.

The error messages you get when you fire up an "Embedded" datastore on
a directory that is either locked or non-existent didn't feel that
intuitive. The locked message says something like "cannot create
neoidb" or something similar rather than informing that the store was
already in use.

Once everything was running I had two issues. The first was having to
open a transaction just to read data seemed wrong. I see pure read
data as being one of the most common tasks and if I am not going to be
changing anything I don't see why I have to manage a transaction.

Secondly the property setting felt quite cumbersome, I would expect to
be able to set multiple Properties via a Map<String, type> for
example. I also think it should be part of the Core API to retrieve
Nodes by Property although if I am reading the documentation correctly
I think that might already be on your roadmap.

Again it might be just to do with the name but I would not expect to
have to explicitly shutdown an Embedded process. The shutdown should
be on the finalizer for the server. Once an Embedded object goes out
of scope it is, to my mind, not in use any longer.

Finally Traversing queries again felt quite heavyweight, I felt that
some things like Direction.BOTH and StopEvaluator.END_OF_GRAPH could
be assumed unless I stated otherwise. I felt that maybe a Traverser
Builder would have helped my pain by creating Traversers with common
characteristics quickly.

The same is true of nodes as I kind of envisaged a builder that would
build up a set of properties and perhaps even the relationships and
the build the required node and store it.

So to sum up, things I liked: a working graph database(!),
relationships being first order.

Things that were difficult: micromanging the database process, lack of
lightweight query modes, ceremony for node creation.

I don't know if I am going to get time next week but I might try and
generate some code illustrating what I mean about wrapping the current
API in something that assumes basic options until overridden.

Neo Technology, www.neotechnology.com
Cell: +46 733 462 271 | US: 206 403 8808
Neo mailing list

Reply via email to