Yep, absolutely. Probably won't get a lot done this week though as I'm on
holiday in México at the moment and don't have much in the way of dev kit,
plus the wireless is a little flaky. That said, I'll start poking it if I
get the time and see how far I get.
So in summary, assuming we are going to allow passing both nodes and
relationships as parameters, the bits I'll look at adding will be as
follows:
- positional/named parameter capabilities for the load method (each
parameter can designate a Node or Relationship)
- support for embedding parameterised Nodes within GEOFF relationship
descriptors:
(node1)-[rname:rtype]->(node2)
(node1)-[rname:rtype]->{param}
{param}-[rname:rtype]->{param}
{param}-[rname:rtype]->(node2)
(May throw WrongParameterTypeException if start or end node param is
actually a Relationship)
- new syntax allowing properties to be assigned to parameterised entities
(Nodes or Relationships):
{param} {key:value, key:value, ...}
- alteration to existing index entry syntax to move away from braces
(although possibly maintaining backward compatibility):
|index|->(node) {key:value}
|index|->[rel] {key:value}
- new syntax allowing index entries for parameterised entities:
|index|->{param} {key:value}
Agreed?
*Nigel Small*
Phone: +44 7814 638 246
Blog: http://nigelsmall.name/
GTalk: [email protected]
MSN: [email protected]
Skype: technige
Twitter: @technige <https://twitter.com/#!/technige>
LinkedIn: http://uk.linkedin.com/in/nigelsmall
On 12 November 2011 21:14, Peter Neubauer
<[email protected]>wrote:
> Hi there,
> I think prototyping a parameter approach to start with would be great!
> Nigel, you up for it?
>
> Cheers,
>
> /peter neubauer
>
> GTalk: neubauer.peter
> Skype peter.neubauer
> Phone +46 704 106975
> LinkedIn http://www.linkedin.com/in/neubauer
> Twitter http://twitter.com/peterneubauer
>
> http://www.neo4j.org - NOSQL for the Enterprise.
> http://startupbootcamp.org/ - Öresund - Innovation happens HERE.
>
>
>
> On Sat, Nov 12, 2011 at 12:30 PM, Nigel Small <[email protected]>
> wrote:
> > ...noticed my last example didn't render properly, Should have been:
> >
> > (dad) {"name":"Nigel"}
> > (son1) {"name":"Joshua"}
> > (son2) {"name":"Stephen"}
> > (dad)-[:FATHER_OF]->(son*)
> > (son*) {"lastname","Small")
> >
> > Hope that works this time!
> > *
> > *
> > *Nigel Small*
> > Phone: +44 7814 638 246
> > Blog: http://nigelsmall.name/
> > GTalk: [email protected]
> > MSN: [email protected]
> > Skype: technige
> > Twitter: @technige <https://twitter.com/#!/technige>
> > LinkedIn: http://uk.linkedin.com/in/nigelsmall
> >
> >
> >
> > On 12 November 2011 11:26, Nigel Small <[email protected]> wrote:
> >
> >> 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: [email protected]
> >> MSN: [email protected]
> >> Skype: technige
> >> Twitter: @technige <https://twitter.com/#!/technige>
> >> LinkedIn: http://uk.linkedin.com/in/nigelsmall
> >>
> >>
> >>
> >> On 12 November 2011 05:44, Michael Hunger <
> >> [email protected]> 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: [email protected]
> >>> > MSN: [email protected]
> >>> > Skype: technige
> >>> > Twitter: @technige <https://twitter.com/#!/technige>
> >>> > LinkedIn: http://uk.linkedin.com/in/nigelsmall
> >>> >
> >>> >
> >>> >
> >>> > On 11 November 2011 22:10, Peter Neubauer
> >>> > <[email protected]>wrote:
> >>> >
> >>> >> Nigel,
> >>> >> On Thu, Nov 10, 2011 at 11:01 PM, Nigel Small <
> [email protected]>
> >>> >> 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
> >>> >> [email protected]
> >>> >> https://lists.neo4j.org/mailman/listinfo/user
> >>> >>
> >>> > _______________________________________________
> >>> > Neo4j mailing list
> >>> > [email protected]
> >>> > https://lists.neo4j.org/mailman/listinfo/user
> >>>
> >>> _______________________________________________
> >>> Neo4j mailing list
> >>> [email protected]
> >>> https://lists.neo4j.org/mailman/listinfo/user
> >>>
> >>
> >>
> > _______________________________________________
> > Neo4j mailing list
> > [email protected]
> > https://lists.neo4j.org/mailman/listinfo/user
> >
> _______________________________________________
> Neo4j mailing list
> [email protected]
> https://lists.neo4j.org/mailman/listinfo/user
>
_______________________________________________
Neo4j mailing list
[email protected]
https://lists.neo4j.org/mailman/listinfo/user
