Hi

I'm working on the jruby neo4j/lucene hybrid
(http://github.com/andreasronge/neo4j/tree/master)
Neo4j is used for storage and traversal, and lucene for indexing/quering.
I have implemented an event system on top of neo4j. The lucene index
gets updated by listening to those events.

In Neo4j.rb we also try to make people think they are working with
ruby objects instead of java nodes and relationships.
* rubyish syntax for neo properties (no need to write getters and setters).
* rubyish syntax for traversal of relationships, example:
person.friends.each {} or person.relations.incoming[:friends].each {}
* adding/deleting relationships, persons.friends << andreas
* mapping of nodes and relationships to ruby classes (marshal and
unmarshal of ruby objects/nodes/relationships)

Future plans ?
* Have a common (limited) query language for both traversal and using index.
* Make it possible to create your own index (not lucene) with neo
nodes by listening to those events

I think that by adding better support for indexing/quering will make
Neo4j useful in a wider range of projects.
Looking forward to see what neo4j would look like in groovy.

/Andreas

On Fri, Nov 28, 2008 at 4:11 PM, Guillaume Laforge <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I had an email exchange with Emil this morning about what Groovy could
> bring to using Neo4J. I think using a dynamic language with a graph
> database can make a lot of sense, as it's easier to work with a "less
> strict" language with semi structured data not requiring heavyweight
> set-in-stone schemas.
>
> Emil suggested I reproduce the email on this mailing-list, so I'm
> happy to echo my small brainstorming session below.
>
> I haven't used Neo4J so far, so I just based my ideas on the
> information I gathered looking at the quick start tutorial, so bare
> with me if I'm totally nuts ;-)
>
> Guillaume
>
>
> ---------------%<--------------------------------------
>
> Hi Emil,
>
> First, a small introduction: I'm the project lead of the Groovy
> dynamic language.
> I've stumbled upon your presentation of Neo at QCon, on slideshare,
> and saw the mention of Groovy near the end :-)
> I've always been interested in triplestores, object databases, and so
> on, and thought that the flexibility they offer is something I really
> miss in relational databases.
> I'd love to use something like JCR, triplestores, or now Neo! for a
> pet project I had a while ago.
> I wish I had been at QCon this year, I would have loved to attend your
> session, but that was not the case.
>
> I haven't downloaded and tried Neo yet, but if I find some time, I'd
> be happy to give it a try.
> As you were mentioning that Groovy should probably work well with Neo,
> yes, I'm pretty certain it does, and I'm sure we could bring some
> Groovyisms into the loop to make using Neo even more seamless and
> nice.
>
> For instance, if I look at your quick start example:
>
> Node firstNode = neo.createNode();
> Node secondNode = neo.createNode();
> Relationship relationship = firstNode.createRelationshipTo(
> secondNode, MyRelationshipTypes.KNOWS );
>
> firstNode.setProperty( "message", "Hello, " );
> secondNode.setProperty( "message", "world!" );
> relationship.setProperty( "message", "brave Neo " );
>
> Groovy handles the setProperty/getProperty methods in a particular
> fashion, and without doing anything special, you should be able to
> directly use this nicer syntax in Groovy:
>
> firstNode.message = "Hello"
> secondNode.message = "world!"
> relationship.message = "brave Neo"
>
> It really gives people the impression of working with real objects,
> with real properties or methods.
>
> With maps or expandos in Groovy, you can already manipulate
> quasi-beans with that syntax, and people may potentially not need to
> manipulate Node or Relationship directly, but could use these maps /
> expandos instead, and it would only be when storing these in the graph
> database that you could "coerce" the type to Node or Relationship.
>
> More concretely:
>
> def firstNode = [:]
> firstNode.message = "Hello"
>
> And you could then just call some store() method in your APIs --
> although it seems in the tutorial, there's no need to "store", just
> creating the nodes and relationships are enough.
>
> Also for relationships, we could imagine using Groovy's native list
> syntax for representing such triples (and using static import for
> KNOWS):
>
> def relationship = [ firstNode, KNOWS, secondNode ]
>
> Combining everything:
>
> [
>   [name: "Neo"],
>   [KNOWS: [since: someDate],
>   [name: "Trinity"]
> ]
>
> I was also mentioning coercion, as you can create custom type coercion
> in Groovy (kind of a cast, if you wish, but you can transform
> something into some other type):
>
> [name: "Neo"] as Node
> [ firstNode, KNOWS, secondNode ] as Relationship
>
> Or simply at declaration time:
>
> Node neo = [name: "Neo"]
> Relationship rel =  [ firstNode, KNOWS, secondNode ]
>
> Anyway... enough brainstorming for now, but a graph database like Neo
> and a dynamic language like Groovy, and you can really really have
> fun.
> Congratulations for a great graph database project!
> Keep up the good work.
>
> --
> Guillaume Laforge
> Groovy Project Manager
> Head of Groovy Development at SpringSource
> http://www.springsource.com/g2one
> _______________________________________________
> Neo mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user
>
_______________________________________________
Neo mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Reply via email to