Re: [Neo4j] py2neo 0.982
First off, thanks for py2neo. I think i found a bug that prevents from using javascript filters when traversing over rest: http://py2neo.org/docs/api/py2neo.neo4j-pysrc.html#TraversalDescription.filter Instead of body, key is named name. Since you're on vacation i've taken justice of sending you a pull request over on github with proposed fix. Enjoy your chillaxing. ___ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo4j] py2neo 0.982
Hi Krzysztof Yes, certainly looks like it's a bug, however I'm convinced this has changed from the original REST docs on which I based this code. Can't find a copy though and since your fix looks to apply to both 1.4 and 1.5 then consider it merged! Thanks for your help :-) Nige *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 2011/11/15 Krzysztof Raczyński racz...@gmail.com First off, thanks for py2neo. I think i found a bug that prevents from using javascript filters when traversing over rest: http://py2neo.org/docs/api/py2neo.neo4j-pysrc.html#TraversalDescription.filter Instead of body, key is named name. Since you're on vacation i've taken justice of sending you a pull request over on github with proposed fix. Enjoy your chillaxing. ___ 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
Re: [Neo4j] py2neo 0.982
No problem, on the other hand the name parameter is still valid, since there are two named filters: all and all_but_start_node, and whatever filters someone may add themselves. I also have one issue with Node class, i really like the way original JPype bindings work - i.e. i can use node.loves(cake, how='deeply') to define a relationship, and also properties are easily accessible like class members. This could be easily implemented with some dose of __getattr__ magic, and pretty easily too. Question is wether such change in API would be accepted? Also, automatic binding of properties to node instances would be awesome too. Please let me know if you are interested, i'd gladly help. ___ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo4j] py2neo 0.982
So that we can support both, I've made some further changes to the TraversalDescription class. I have replaced prune and filter with: builtin_prune_evaluator(self, name) prune_evaluator(self, language, body) builtin_return_filter(self, name) return_filter(self, language, body) This does break some backward compatibility with the methods but does provide more clarity than the original. I'm also aware that some of this has been deprecated within the core API; however, since this does not yet appear to be reflected within the REST API, this is probably the best option for now. WRT your suggestion for the Node class: I'm happy to consider it but will need to read up more on the JPype bindings as I'm not familiar with them. Could you submit an issue, preferably containing a link to docs describing the interface you describe, and I'll have a proper look. 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 2011/11/15 Krzysztof Raczyński racz...@gmail.com No problem, on the other hand the name parameter is still valid, since there are two named filters: all and all_but_start_node, and whatever filters someone may add themselves. I also have one issue with Node class, i really like the way original JPype bindings work - i.e. i can use node.loves(cake, how='deeply') to define a relationship, and also properties are easily accessible like class members. This could be easily implemented with some dose of __getattr__ magic, and pretty easily too. Question is wether such change in API would be accepted? Also, automatic binding of properties to node instances would be awesome too. Please let me know if you are interested, i'd gladly help. ___ 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
Re: [Neo4j] py2neo 0.982
No need to, i submitted a pull request with that change. I will also submit my proposed index syntax changes. I'm no good at git, so i may or may not screw this up. As far as changes you wrote about, i think we should move it to one method, and rely on arguments supplied by user to know which prune/filter to use. Also, are there any other language options besides javascript for evaluators? Cheers ___ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
Re: [Neo4j] py2neo 0.982
Hi Krzysztof Having looked at your Pull Request, I can see that your syntax certainly provides a easy and readable way to create relationships to nodes. However, I have a couple of reservations: 1. This essentially uses a get operation to carry out a write behind the scenes. I would generally try to avoid something which is intuitively read-only from having side-effects such as this. 2. Using the __getattr__ method in this way precludes using it to access Node properties which is, arguably, the more obvious use (even though __getitem__ is already used here). I don't entirely dislike the idea but given this is really just syntactic sugar, I'd like to hear other's opinions on this. The new prune/filter methods aren't restricted purely to JavaScript: they now simply have built-in and custom variants with clearer naming. My philosophy is generally to swing towards longer/clearer and more descriptive names as opposed to trying to save a few keystrokes and making one function do multiple things. 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 2011/11/16 Krzysztof Raczyński racz...@gmail.com No need to, i submitted a pull request with that change. I will also submit my proposed index syntax changes. I'm no good at git, so i may or may not screw this up. As far as changes you wrote about, i think we should move it to one method, and rely on arguments supplied by user to know which prune/filter to use. Also, are there any other language options besides javascript for evaluators? Cheers ___ 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
Re: [Neo4j] py2neo 0.982
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.comwrote:
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.comwrote:
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
Re: [Neo4j] py2neo 0.982
...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.comwrote:
Nigel,
On
Re: [Neo4j] py2neo 0.982
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
Re: [Neo4j] py2neo 0.982
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.comwrote:
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
Re: [Neo4j] py2neo 0.982
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
Re: [Neo4j] py2neo 0.982
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.comwrote:
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
Re: [Neo4j] py2neo 0.982
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.comwrote:
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
Re: [Neo4j] py2neo 0.982
Thanks Nigel for working hard on Py2neo - it's becoming a very cool binding! Also, GEOFF for the clean insertion of data is starting to shape up - I am hoping to get server side support in after the release :) Related to this is another issue. How are we going to insert subgraphs that refer to existing nodes? There are a number of interesting scenarios here: - insert data as part of a JSON payload to existing nodes, encoded in GEOFF (kind of document substructures) - something like http://docs.neo4j.org/chunked/snapshot/rest-api-node-properties.html#rest-api-set-property-on-node but with a GEOFF payload that is resulting in a new subgraph - insert a subgraph, but as part of the insertion, attach the subgraph to an existing stucture - have PQL support mutating statements (INSERT, UPDATE etc) and maybe use GEOFF to describe substructures for mutations. Any thoughts? 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 Tue, Nov 8, 2011 at 9:02 AM, Nigel Small ni...@nigelsmall.name wrote: Hi all Have just released a small but hopefully significant (performance-wise) upgrade to py2neo: a rewrite to geoff.py which submits the entire set of data in a single self-referential batch. Available from GitHub and PyPI. 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 ___ 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] py2neo 0.982
Hi all Have just released a small but hopefully significant (performance-wise) upgrade to py2neo: a rewrite to geoff.py which submits the entire set of data in a single self-referential batch. Available from GitHub and PyPI. 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 ___ Neo4j mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
