Hi all, Robert Rees gave Neo4j a shot last week, trying to drive it from Groovy but came away disappointed:
http://twitter.com/rrees/statuses/1022507656 I asked why: http://twitter.com/emileifrem/status/1023049302 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 subscribed. See mail below. -EE ---------- Forwarded message ---------- From: Robert Rees <[EMAIL PROTECTED]> Date: Fri, Nov 28, 2008 at 4:04 PM Subject: Starting pain with Neo4j To: [EMAIL PROTECTED] 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. -- Emil Eifrém, CEO [EMAIL PROTECTED] Neo Technology, www.neotechnology.com Cell: +46 733 462 271 | US: 206 403 8808 _______________________________________________ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
