Hi Michael
Completely agree on named parameters - I'd like to support both named and
positional - both have advantages.
I also like the idea of the {foo} syntax as consistency with Cypher is what
I have tried to provide all along here. I actually don't believe that it
will be confusing with JSON (even with the composite descriptor syntax) but
this notation is unfortunately already used by the index entry syntax:
{my_index}->(my_node)
Having said that, this clash doesn't have to give us a major problem. We
could deprecate the existing index entry syntax (possibly maintaining
backward compatibility for a while with a bit of regex jiggery-pokery) and
replace it with something new, such as:
<my_index>->(my_node)
or
|my_index|->(my_node)
Back to parameters. There's an amazing amount of strength in the concept of
multiple entities specified by a single token so agree that we should look
further into that. Behind the scenes, it should be simple enough to add
multiple entries when one of these is encountered, by iterating through the
items. Even more Interesting with something like:
{parents}-[:PARENT_OF]->{children}
which could break down to:
(father)-[:PARENT_OF]->(child1)
(father)-[:PARENT_OF]->(child2)
(mother)-[:PARENT_OF]->(child1)
(mother)-[:PARENT_OF]->(child2)
The comma syntax, again, looks very useful. Would this lead to us wanting
some form of pattern matching as well?
*(dad) {"name":"Nigel"}**(son1) {"name":"Joshua"}**(son2)
{"name":"Stephen"}**(dad)-[:FATHER_OF]->(son*)**(son*)
{"lastname","Small")*
*
*
*Cheers*
*Nigel Small*
Phone: +44 7814 638 246
Blog: http://nigelsmall.name/
GTalk: ni...@nigelsmall.name
MSN: nasm...@live.co.uk
Skype: technige
Twitter: @technige <https://twitter.com/#!/technige>
LinkedIn: http://uk.linkedin.com/in/nigelsmall
On 12 November 2011 05:44, Michael Hunger
<michael.hun...@neotechnology.com>wrote:
> Nigel,
>
> Sounds good, although I'd rather have named parameters as well, otherwise
> parameter indexes will easily get unwieldy.
>
> I would like to propose to use the same syntax cypher uses for parameters
> (that's also the syntax used by the batch-inserter)
>
> aka. {0} and {name}
>
> > (dad)-[:FATHER_OF]->(son2)
> > {1}-[:FAMILY]->(dad)
>
> Might be a bit confusing wrt the json, But I want consistency :)
>
> Interesting part would also be when those parameters not only refer to a
> single node or relationship but an collections of those.
>
> So one could take the output of a traversal or cypher query (with aliases
> or position) and pass them into the geoff reader which then connects or
> updates all of them appropriately.
>
> Allowing us to do mass-updates or structural connections in one go.
>
> (dad)-[:FATHER_OF]->{children}
> {children} {"lastname" : "Small"}
>
> Btw. that reminds me of a version of the geoff syntax that might compact
> many files:
> > (dad) {"name":"Nigel"}
> > (son1) {"name":"Joshua"}
> > (son2) {"name":"Stephen"}
> > (dad)-[:FATHER_OF]->(son1,son2)
> > (son1,son2) {"lastname","Small")
>
> Michael
>
> Am 12.11.2011 um 00:07 schrieb Nigel Small:
>
> > Hi Peter
> >
> > Imagine we are trying to inject a simple graph, such as the following:
> >
> > (dad) {"name":"Nigel"}
> > (son1) {"name":"Joshua"}
> > (son2) {"name":"Stephen"}
> > (dad)-[:FATHER_OF]->(son1)
> > (dad)-[:FATHER_OF]->(son2)
> >
> > Currently, this would be loaded into graphspace without any attachment to
> > existing structures; a join would have to be made *after* the load.
> >
> > If we instead consider parameterising the load, e.g.
> loadIntoNeo4j(reader,
> > graphDB, someNode, otherNode, ...), we can reference the supplied nodes
> > from within the GEOFF data. I think that ($n) notation would be quite
> > useful here as it is already familiar from bash etc. This might therefore
> > turn the above subgraph into:
> > *
> >
> > (dad) {"name":"Nigel"}
> > (son1) {"name":"Joshua"}
> > (son2) {"name":"Stephen"}
> > (dad)-[:FATHER_OF]->(son1)
> > (dad)-[:FATHER_OF]->(son2)
> > ($1)-[:FAMILY]->(dad)
> >
> > ...such that ($1) refers to the first supplied parameter, ($2) would be
> the
> > second and so on. ($0) could possibly refer to the reference node of the
> > destination graph, by definition.
> >
> > Hope this makes sense! What do you reckon?
> >
> > *
> > *Nigel Small*
> > Phone: +44 7814 638 246
> > Blog: http://nigelsmall.name/
> > GTalk: ni...@nigelsmall.name
> > MSN: nasm...@live.co.uk
> > Skype: technige
> > Twitter: @technige <https://twitter.com/#!/technige>
> > LinkedIn: http://uk.linkedin.com/in/nigelsmall
> >
> >
> >
> > On 11 November 2011 22:10, Peter Neubauer
> > <peter.neuba...@neotechnology.com>wrote:
> >
> >> Nigel,
> >> On Thu, Nov 10, 2011 at 11:01 PM, Nigel Small <ni...@nigelsmall.name>
> >> wrote:
> >>> We could possibly create some form of syntax which would designate a
> >> "this"
> >>> node, e.g. (@). This could allow a file to reference it's external
> >> context,
> >>> in this case the node to which we are submitting the subgraph.
> >> What would this look like?
> >>
> >> /peter
> >> _______________________________________________
> >> Neo4j mailing list
> >> User@lists.neo4j.org
> >> https://lists.neo4j.org/mailman/listinfo/user
> >>
> > _______________________________________________
> > Neo4j mailing list
> > User@lists.neo4j.org
> > https://lists.neo4j.org/mailman/listinfo/user
>
> _______________________________________________
> Neo4j mailing list
> User@lists.neo4j.org
> https://lists.neo4j.org/mailman/listinfo/user
>
_______________________________________________
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user
