Hi Guillaume, sounds great. The only thing is that you need a NeoService to create a node. Or you must somehow detect (?) an existing NeoService.
I am not sure, what would be necessary to transform: neo.createNode() into def firstNode [:] somehow the neo (the NeoService instance) needs to be 'injected' Any ideas? Victor 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 > [email protected] > https://lists.neo4j.org/mailman/listinfo/user > _______________________________________________ Neo mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
