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
