You can also do some fun things like:
def myNodeName = "firstName"
assert person."${myNodeName}" == "firstName"
:-)
On Fri, Dec 12, 2008 at 11:41 AM, Mattias Persson
<matt...@neotechnology.com> wrote:
> Awesome,
>
> that takes care of that then, thanks!
>
> 2008/12/12 Guillaume Laforge <glafo...@gmail.com>:
>> In Groovy, you can "quote" method names and properties.
>>
>> So when you have weirdo characters, you can do that instead:
>>
>> myNode."super - funky + node / name" = "something.
>>
>>
>> On Fri, Dec 12, 2008 at 11:36 AM, Mattias Persson
>> <matt...@neotechnology.com> wrote:
>>> Hmm, this thread is probably dead?
>>>
>>> But, I just thought about the:
>>>
>>> myNode.name = "Mattias"
>>> myNode.someProperty = "Something else"
>>>
>>> Keep in mind that property keys have no restrictions as to length or
>>> content which means a property key can contain spaces and '='
>>> characters and what not. f.ex.
>>>
>>> myNode.a property with spaces in it = "Hello there"
>>>
>>> Wouldn't work, right?
>>>
>>> Could you use the real methods (setProperty/getProperty/hasProperty)
>>> for such keys instead?
>>>
>>> 2008/12/7 Stig Lau <stig....@gmail.com>:
>>>> I've tossed up a demo of Neo4J vs Groovy which shows Neo4J running in
>>>> Groovy with the help of some Maven magic. Sadly nough, I didn't get
>>>> Guillaume's propositions working, so I'm leaving the ball over to the
>>>> guys who know Groovy a little better than me.
>>>> The project is packaged as a Maven Archetype, as a test of improving
>>>> deployment of sourcecode. Instructions are posted on the blog. The
>>>> source code is hosted on Mercurial, so feel free to move it to a VCS
>>>> of choice, as I consider it property of the Neo4J community.
>>>> -Stig,
>>>>
>>>> http://stigl.wordpress.com/groovy-does-neo4j-thanks-to-maven-simplicity
>>>>
>>>>> From: "Guillaume Laforge"
>>>>> Subject: [Neo] Groovy and Neo4J
>>>>>
>>>>> 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.
>>>>>
>>>>> ---------------%<--------------------------------------
>>>>>
>>>>> 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
>>>>
>>>
>>>
>>>
>>> --
>>> Mattias Persson, [matt...@neotechnology.com]
>>> Neo Technology, www.neotechnology.com
>>> _______________________________________________
>>> Neo mailing list
>>> User@lists.neo4j.org
>>> https://lists.neo4j.org/mailman/listinfo/user
>>>
>>
>>
>>
>> --
>> 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
>>
>
>
>
> --
> Mattias Persson, [matt...@neotechnology.com]
> Neo Technology, www.neotechnology.com
> _______________________________________________
> Neo mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user
>
--
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
