Sounds great to me Nigel! 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 Sun, Nov 13, 2011 at 12:55 AM, Nigel Small <ni...@nigelsmall.name> wrote: > 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: 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 21:14, Peter Neubauer > <peter.neuba...@neotechnology.com>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 <ni...@nigelsmall.name> >> 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: 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 11:26, Nigel Small <ni...@nigelsmall.name> 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: 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 >> > >> _______________________________________________ >> 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
