Re: [Neo4j] py2neo - GEOFF enhancements

[Nigel Small]

Having played around with some ASCII art (quite good fun actually!) it is
starting to feel more natural to re-order the index entries, so that the
key:value part is both consistent with existing syntax and adjacent to the
index reference. I have ended up with:

# ADD ENTRY:
# ensure node "bert" has an entry in index "Scientists"
# where "name" = "Einstein"
(bert)<=|Scientists| {"name": "Einstein"}

Here I have altered the "->" arrow to "<=" - these arrows have a different
meaning to those used for relationships so it is fair to differentiate them
visually. The reversal of order of the components not only feels more
natural but also allows us to also produce things like:

# REMOVE ENTRY:
# ensure node "bert" does not have an entry in index "Scientists"
# where "tidy_hair" = true
(bert)!=|Scientists| {"tidy_hair": true}

# LOOKUP ENTRY:
# define node "bert" as the (first?) entry in index "Scientists"
# where "name" = "Einstein"
(bert):=|Scientists| {"name": "Einstein"}

On a side note, I've also been pondering some built-in hook syntax which is
slightly borrowed from XPath:

# Built-in hook for reference node:
{/}-[:THINGS]->(foo)

# Built-in hooks for sub-reference nodes:
{/THINGS}-[:THING]->(thing)

WDYT?

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 
LinkedIn: http://uk.linkedin.com/in/nigelsmall



On 2 December 2011 01:02, Michael Hunger
wrote:

> Peter and I have been discussing what interchange format we'd like to have
> for applications feeding data into a graph.
>
> And geoff seems to be quite a good choice.
>
> Modifying and accessing indexes (much like in-file-hooks) would be a part
> of that.
>
> So what I imagine is a set of connectors to outside services which are
> producing geoff which is then consumed by a server plugin (e.g. for hosted
> neo4j services on heroku). Much like STDIN and STDOUT between unix command
> line tools.
>
> Having a declarative format that aligns more with cypher is preferable to
> a imperative format like the REST API or Gremlin.
>
> That's why I would also like to look into aligning the syntax with the
> cypher syntax, actually I'm more fond of the iconographic syntax but there
> are some drawbacks on readability for people.
>
> That's some of the reasoning behind it.
>
> Cheers
>
> Michael
>
> Am 02.12.2011 um 01:49 schrieb Nigel Small:
>
> > Hi Michael
> >
> > GEOFF was originally conceived as a graph serialisation format and, as
> > such, was intended to represent a snapshot of entities at a particular
> > point in time instead of, as you are discussing, a programmatic set of
> > actions (add, replace, remove, etc). That said, these ideas are still
> worth
> > exploring...
> >
> > First off, since hooks are the "variables" of GEOFF, it would seem
> > consistent to use those for assigning the return values of index lookups
> > and queries. Something like the following could be used to perform an
> index
> > query, assign the result to a hook and use that hook to build a
> > relationship:
> >
> > {foo} := |index| @ {"key": "value"}
> > {foo}-[:KNOWS]->(bar)
> >
> > Actually, since the index query may result in multiple returned entities,
> > we might want to limit to the first item returned:
> >
> > {foo} := |index| @ {"key":"value"}
> > {foo.1}-[:KNOWS]->(bar)
> >
> > Using the other operators for adding, removing and replacing index
> entries,
> > this would make...
> >
> > # add node bert to index at foo:bar
> > |index| @ {"foo": "bar"} += (bert)
> >
> > # remove node bert from index at foo:bar
> > |index| @ {"foo": "bar"} -= (bert)
> >
> > # replace node with bert in index at foo:bar
> > |index| @ {"foo": "bar"} := (bert)
> >
> > So essentially, we would be looking at at least the following
> requirements:
> >
> >   1. Allow hooks to hold multiple entities instead of just a single
> entity
> >   2. Allow assignment to hooks
> >   3. Implement an "@" operator to allow inline index queries
> >   4. Implement assignment, addition and removal operators to indexes
> >
> > These ideas would turn GEOFF into much more of a programming language
> than
> > a notation for serialisation: a big change and one which would
> potentially
> > require another significant rewrite. I'm not against doing this but I'm
> > wondering if this is a valuable direction to go in and whether, if we
> were
> > to do this, it would be better to start from first principles instead.
> > Would this fill a gap that none of the other current options can?
> > Cheers
> >
> > 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 
> > LinkedIn: http://uk.linkedin.com/in/nigelsmall
> >
> >
> >
> > On 1 December 2011 21:47, Michael Hunger
> > wrote:
> >
> >> Nigel,
> >>
> >> is it po

Re: [Neo4j] py2neo - GEOFF enhancements

[Nigel Small]

OK cool, that gives me some context. I'll put together some ideas over the
next few days and we can compare notes :-)

*Nigel Small*
Phone: +44 7814 638 246
Blog: http://nigelsmall.name/
GTalk: ni...@nigelsmall.name
MSN: nasm...@live.co.uk
Skype: technige
Twitter: @technige 
LinkedIn: http://uk.linkedin.com/in/nigelsmall



On 2 December 2011 01:02, Michael Hunger
wrote:

> Peter and I have been discussing what interchange format we'd like to have
> for applications feeding data into a graph.
>
> And geoff seems to be quite a good choice.
>
> Modifying and accessing indexes (much like in-file-hooks) would be a part
> of that.
>
> So what I imagine is a set of connectors to outside services which are
> producing geoff which is then consumed by a server plugin (e.g. for hosted
> neo4j services on heroku). Much like STDIN and STDOUT between unix command
> line tools.
>
> Having a declarative format that aligns more with cypher is preferable to
> a imperative format like the REST API or Gremlin.
>
> That's why I would also like to look into aligning the syntax with the
> cypher syntax, actually I'm more fond of the iconographic syntax but there
> are some drawbacks on readability for people.
>
> That's some of the reasoning behind it.
>
> Cheers
>
> Michael
>
> Am 02.12.2011 um 01:49 schrieb Nigel Small:
>
> > Hi Michael
> >
> > GEOFF was originally conceived as a graph serialisation format and, as
> > such, was intended to represent a snapshot of entities at a particular
> > point in time instead of, as you are discussing, a programmatic set of
> > actions (add, replace, remove, etc). That said, these ideas are still
> worth
> > exploring...
> >
> > First off, since hooks are the "variables" of GEOFF, it would seem
> > consistent to use those for assigning the return values of index lookups
> > and queries. Something like the following could be used to perform an
> index
> > query, assign the result to a hook and use that hook to build a
> > relationship:
> >
> > {foo} := |index| @ {"key": "value"}
> > {foo}-[:KNOWS]->(bar)
> >
> > Actually, since the index query may result in multiple returned entities,
> > we might want to limit to the first item returned:
> >
> > {foo} := |index| @ {"key":"value"}
> > {foo.1}-[:KNOWS]->(bar)
> >
> > Using the other operators for adding, removing and replacing index
> entries,
> > this would make...
> >
> > # add node bert to index at foo:bar
> > |index| @ {"foo": "bar"} += (bert)
> >
> > # remove node bert from index at foo:bar
> > |index| @ {"foo": "bar"} -= (bert)
> >
> > # replace node with bert in index at foo:bar
> > |index| @ {"foo": "bar"} := (bert)
> >
> > So essentially, we would be looking at at least the following
> requirements:
> >
> >   1. Allow hooks to hold multiple entities instead of just a single
> entity
> >   2. Allow assignment to hooks
> >   3. Implement an "@" operator to allow inline index queries
> >   4. Implement assignment, addition and removal operators to indexes
> >
> > These ideas would turn GEOFF into much more of a programming language
> than
> > a notation for serialisation: a big change and one which would
> potentially
> > require another significant rewrite. I'm not against doing this but I'm
> > wondering if this is a valuable direction to go in and whether, if we
> were
> > to do this, it would be better to start from first principles instead.
> > Would this fill a gap that none of the other current options can?
> > Cheers
> >
> > 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 
> > LinkedIn: http://uk.linkedin.com/in/nigelsmall
> >
> >
> >
> > On 1 December 2011 21:47, Michael Hunger
> > wrote:
> >
> >> Nigel,
> >>
> >> is it possible to also do index-lookups in geoff?
> >> and use those as nodes or rels or even as hooks for later on?
> >>
> >> I'm also toying with two other ideas:
> >> #1 using indexes as the third primitive besides nodes and rels in geoff
> >> just with a different delimeter (e.g. | as you already have)
> >> #2 giving indexes a similar semantics as relationships to category nodes
> >> (which is the same for in-graph indexes, where the index-name is the
> >> category-type and indexed key-values are properties on the relationship
> or
> >> relationships)
> >>
> >> I'm not really satisfied with the syntaxes I came up with and would like
> >> to brainstorm that.
> >>
> >> |index| -{"foo":"bar"} ->(bert)
> >>
> >>
> >> some ideas for alternative index syntaxes
> >> #add
> >> |index:{"foo":"bar"}|+={foo}
> >> # replace
> >> |index:{"foo":"bar"}|={foo}
> >> # remove
> >> |index:{"foo":"bar"}|-={foo}
> >>
> >> #query
> >> |index:{"foo":"bar"}| -[:KNOWS]->(bert)
> >> |index:"querystring"| -[:KNOWS]->(bert)
> >>
> >> Am 01.12.2011 um 01:32 schrieb Nigel Small:
> >>
> >>> Peter: I am happy with the current state 

Re: [Neo4j] py2neo - GEOFF enhancements

[Michael Hunger]

Peter and I have been discussing what interchange format we'd like to have for 
applications feeding data into a graph.

And geoff seems to be quite a good choice.

Modifying and accessing indexes (much like in-file-hooks) would be a part of 
that.

So what I imagine is a set of connectors to outside services which are 
producing geoff which is then consumed by a server plugin (e.g. for hosted 
neo4j services on heroku). Much like STDIN and STDOUT between unix command line 
tools.

Having a declarative format that aligns more with cypher is preferable to a 
imperative format like the REST API or Gremlin. 

That's why I would also like to look into aligning the syntax with the cypher 
syntax, actually I'm more fond of the iconographic syntax but there are some 
drawbacks on readability for people.

That's some of the reasoning behind it.

Cheers

Michael

Am 02.12.2011 um 01:49 schrieb Nigel Small:

> Hi Michael
> 
> GEOFF was originally conceived as a graph serialisation format and, as
> such, was intended to represent a snapshot of entities at a particular
> point in time instead of, as you are discussing, a programmatic set of
> actions (add, replace, remove, etc). That said, these ideas are still worth
> exploring...
> 
> First off, since hooks are the "variables" of GEOFF, it would seem
> consistent to use those for assigning the return values of index lookups
> and queries. Something like the following could be used to perform an index
> query, assign the result to a hook and use that hook to build a
> relationship:
> 
> {foo} := |index| @ {"key": "value"}
> {foo}-[:KNOWS]->(bar)
> 
> Actually, since the index query may result in multiple returned entities,
> we might want to limit to the first item returned:
> 
> {foo} := |index| @ {"key":"value"}
> {foo.1}-[:KNOWS]->(bar)
> 
> Using the other operators for adding, removing and replacing index entries,
> this would make...
> 
> # add node bert to index at foo:bar
> |index| @ {"foo": "bar"} += (bert)
> 
> # remove node bert from index at foo:bar
> |index| @ {"foo": "bar"} -= (bert)
> 
> # replace node with bert in index at foo:bar
> |index| @ {"foo": "bar"} := (bert)
> 
> So essentially, we would be looking at at least the following requirements:
> 
>   1. Allow hooks to hold multiple entities instead of just a single entity
>   2. Allow assignment to hooks
>   3. Implement an "@" operator to allow inline index queries
>   4. Implement assignment, addition and removal operators to indexes
> 
> These ideas would turn GEOFF into much more of a programming language than
> a notation for serialisation: a big change and one which would potentially
> require another significant rewrite. I'm not against doing this but I'm
> wondering if this is a valuable direction to go in and whether, if we were
> to do this, it would be better to start from first principles instead.
> Would this fill a gap that none of the other current options can?
> Cheers
> 
> 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 
> LinkedIn: http://uk.linkedin.com/in/nigelsmall
> 
> 
> 
> On 1 December 2011 21:47, Michael Hunger
> wrote:
> 
>> Nigel,
>> 
>> is it possible to also do index-lookups in geoff?
>> and use those as nodes or rels or even as hooks for later on?
>> 
>> I'm also toying with two other ideas:
>> #1 using indexes as the third primitive besides nodes and rels in geoff
>> just with a different delimeter (e.g. | as you already have)
>> #2 giving indexes a similar semantics as relationships to category nodes
>> (which is the same for in-graph indexes, where the index-name is the
>> category-type and indexed key-values are properties on the relationship or
>> relationships)
>> 
>> I'm not really satisfied with the syntaxes I came up with and would like
>> to brainstorm that.
>> 
>> |index| -{"foo":"bar"} ->(bert)
>> 
>> 
>> some ideas for alternative index syntaxes
>> #add
>> |index:{"foo":"bar"}|+={foo}
>> # replace
>> |index:{"foo":"bar"}|={foo}
>> # remove
>> |index:{"foo":"bar"}|-={foo}
>> 
>> #query
>> |index:{"foo":"bar"}| -[:KNOWS]->(bert)
>> |index:"querystring"| -[:KNOWS]->(bert)
>> 
>> Am 01.12.2011 um 01:32 schrieb Nigel Small:
>> 
>>> Peter: I am happy with the current state of the neo4j-geoff code so feel
>> it
>>> should be stable enough to adopt when you wish to do so. I have also
>> made a
>>> couple of recent updates to the documentation, most notably the GEOFF.md
>>> file.
>>> 
>>> Cheers
>>> 
>>> 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 
>>> LinkedIn: http://uk.linkedin.com/in/nigelsmall
>>> 
>>> 
>>> 
>>> On 29 November 2011 23:33, Michael Hunger
>>> wrote:
>>> 
 #1 Thanks
 #2 You're probably right
>>

Re: [Neo4j] py2neo - GEOFF enhancements

[Nigel Small]

Hi Michael

GEOFF was originally conceived as a graph serialisation format and, as
such, was intended to represent a snapshot of entities at a particular
point in time instead of, as you are discussing, a programmatic set of
actions (add, replace, remove, etc). That said, these ideas are still worth
exploring...

First off, since hooks are the "variables" of GEOFF, it would seem
consistent to use those for assigning the return values of index lookups
and queries. Something like the following could be used to perform an index
query, assign the result to a hook and use that hook to build a
relationship:

{foo} := |index| @ {"key": "value"}
{foo}-[:KNOWS]->(bar)

Actually, since the index query may result in multiple returned entities,
we might want to limit to the first item returned:

{foo} := |index| @ {"key":"value"}
{foo.1}-[:KNOWS]->(bar)

Using the other operators for adding, removing and replacing index entries,
this would make...

# add node bert to index at foo:bar
|index| @ {"foo": "bar"} += (bert)

# remove node bert from index at foo:bar
|index| @ {"foo": "bar"} -= (bert)

# replace node with bert in index at foo:bar
|index| @ {"foo": "bar"} := (bert)

So essentially, we would be looking at at least the following requirements:

   1. Allow hooks to hold multiple entities instead of just a single entity
   2. Allow assignment to hooks
   3. Implement an "@" operator to allow inline index queries
   4. Implement assignment, addition and removal operators to indexes

These ideas would turn GEOFF into much more of a programming language than
a notation for serialisation: a big change and one which would potentially
require another significant rewrite. I'm not against doing this but I'm
wondering if this is a valuable direction to go in and whether, if we were
to do this, it would be better to start from first principles instead.
Would this fill a gap that none of the other current options can?
Cheers

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 
LinkedIn: http://uk.linkedin.com/in/nigelsmall



On 1 December 2011 21:47, Michael Hunger
wrote:

> Nigel,
>
> is it possible to also do index-lookups in geoff?
> and use those as nodes or rels or even as hooks for later on?
>
> I'm also toying with two other ideas:
> #1 using indexes as the third primitive besides nodes and rels in geoff
> just with a different delimeter (e.g. | as you already have)
> #2 giving indexes a similar semantics as relationships to category nodes
> (which is the same for in-graph indexes, where the index-name is the
> category-type and indexed key-values are properties on the relationship or
> relationships)
>
> I'm not really satisfied with the syntaxes I came up with and would like
> to brainstorm that.
>
> |index| -{"foo":"bar"} ->(bert)
>
>
> some ideas for alternative index syntaxes
> #add
> |index:{"foo":"bar"}|+={foo}
> # replace
> |index:{"foo":"bar"}|={foo}
> # remove
> |index:{"foo":"bar"}|-={foo}
>
> #query
> |index:{"foo":"bar"}| -[:KNOWS]->(bert)
> |index:"querystring"| -[:KNOWS]->(bert)
>
> Am 01.12.2011 um 01:32 schrieb Nigel Small:
>
> > Peter: I am happy with the current state of the neo4j-geoff code so feel
> it
> > should be stable enough to adopt when you wish to do so. I have also
> made a
> > couple of recent updates to the documentation, most notably the GEOFF.md
> > file.
> >
> > Cheers
> >
> > 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 
> > LinkedIn: http://uk.linkedin.com/in/nigelsmall
> >
> >
> >
> > On 29 November 2011 23:33, Michael Hunger
> > wrote:
> >
> >> #1 Thanks
> >> #2 You're probably right
> >>
> >> #3 You can do the index lookup outside and pass in the IndexHits
> as
> >> being and Iterator
> >> #3 I rather thought of {name} for |people| -> {name: {hook}} as a
> shortcut
> >> for that
> >>
> >> Michael
> >>
> >> But #2 and #3 are probably overkill anyway.
> >>
> >> Cheers
> >>
> >> Michael
> >>
> >> Am 29.11.2011 um 23:59 schrieb Nigel Small:
> >>
> >>> Hi Michael
> >>>
>  Probably better to just return the full map and let the client code
> deal
> >>> with it ? (If it isn't interested it would either just ignore the
> return
> >>> result or discard it quickly).
> >>> Done. Now works as:
> >>>
> >>> Map entities =
> >> GEOFFLoader.loadIntoNeo4j(reader,
> >>> db, hooks);
> >>> Node nodeFoo = (Node) entities.get("(foo)");
> >>> Node nodeBar = (Node) entities.get("(bar)");
> >>>
>  Intention behind longs, is when I get them from an external source
> then
> >>> they can be used to be look up nodes during import.
> >>> This can be done but not sure it's the right place... I'm cautious
> about
> >>> using IDs directly as they aren't very portable. Also, it's 

Re: [Neo4j] py2neo - GEOFF enhancements

[Michael Hunger]

Nigel,

is it possible to also do index-lookups in geoff?
and use those as nodes or rels or even as hooks for later on?

I'm also toying with two other ideas:
#1 using indexes as the third primitive besides nodes and rels in geoff just 
with a different delimeter (e.g. | as you already have) 
#2 giving indexes a similar semantics as relationships to category nodes (which 
is the same for in-graph indexes, where the index-name is the category-type and 
indexed key-values are properties on the relationship or relationships)

I'm not really satisfied with the syntaxes I came up with and would like to 
brainstorm that.

|index| -{"foo":"bar"} ->(bert)


some ideas for alternative index syntaxes
#add
|index:{"foo":"bar"}|+={foo}
# replace
|index:{"foo":"bar"}|={foo}
# remove
|index:{"foo":"bar"}|-={foo}

#query
|index:{"foo":"bar"}| -[:KNOWS]->(bert)
|index:"querystring"| -[:KNOWS]->(bert)

Am 01.12.2011 um 01:32 schrieb Nigel Small:

> Peter: I am happy with the current state of the neo4j-geoff code so feel it
> should be stable enough to adopt when you wish to do so. I have also made a
> couple of recent updates to the documentation, most notably the GEOFF.md
> file.
> 
> Cheers
> 
> 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 
> LinkedIn: http://uk.linkedin.com/in/nigelsmall
> 
> 
> 
> On 29 November 2011 23:33, Michael Hunger
> wrote:
> 
>> #1 Thanks
>> #2 You're probably right
>> 
>> #3 You can do the index lookup outside and pass in the IndexHits as
>> being and Iterator
>> #3 I rather thought of {name} for |people| -> {name: {hook}} as a shortcut
>> for that
>> 
>> Michael
>> 
>> But #2 and #3 are probably overkill anyway.
>> 
>> Cheers
>> 
>> Michael
>> 
>> Am 29.11.2011 um 23:59 schrieb Nigel Small:
>> 
>>> Hi Michael
>>> 
 Probably better to just return the full map and let the client code deal
>>> with it ? (If it isn't interested it would either just ignore the return
>>> result or discard it quickly).
>>> Done. Now works as:
>>> 
>>> Map entities =
>> GEOFFLoader.loadIntoNeo4j(reader,
>>> db, hooks);
>>> Node nodeFoo = (Node) entities.get("(foo)");
>>> Node nodeBar = (Node) entities.get("(bar)");
>>> 
 Intention behind longs, is when I get them from an external source then
>>> they can be used to be look up nodes during import.
>>> This can be done but not sure it's the right place... I'm cautious about
>>> using IDs directly as they aren't very portable. Also, it's not intuitive
>>> whether an ID is for a node or relationship. Would like to get a few
>> votes
>>> on this - I'm happy to be outvoted if the consensus is to do it!
>>> 
 Also can hooks be used for index lookups? (Just asking)
>>> Are you thinking of something like "{People:name=bert}"? If so, this is
>>> quite a distance from where we are currently since every token can only
>>> refer to a single entity, whereas an index lookup could return multiple
>>> results.
>>> 
>>> 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 
>>> LinkedIn: http://uk.linkedin.com/in/nigelsmall
>>> 
>>> 
>>> 
>>> On 29 November 2011 22:09, Michael Hunger
>>> wrote:
>>> 
 Hmm good question, that means the namespace keeps everything around
>> until
 it is gc'ed ?
 
 Probably better to just return the full map and let the client code deal
 with it ? (If it isn't interested it would either just ignore the return
 result or discard it quickly).
 
 Intention behind longs, is when I get them from an external source then
 they can be used to be look up nodes during import.
 
 Also can hooks be used for index lookups? (Just asking)
 
 Thanks a lot
 
 Michael
 
 Am 29.11.2011 um 22:58 schrieb Nigel Small:
 
> Hi Michael
> 
> Doesn't handle iterables (yet) but should be quite easy to add in. What
> purpose did you have behind longs?
> 
> I've just committed a few new methods allowing the Neo4jNamespace
 returned
> from a loadIntoNeo4j call to be used to retrieve new entities by name
 (or a
> map of such). The new methods are:
> 
> public Node getPreexistingNode(String name)
> public Map getPreexistingNodes(String... names)
> public Node getNewlyCreatedNode(String name)
> public Map getNewlyCreatedNodes(String... names)
> public Relationship getPreexistingRelationship(String name)
> public Map getPreexistingRelationships(String...
> names)
> public Relationship getNewlyCreatedRelationship(String name)
> public Map getNewlyCreatedRelationships(String...
> names)
> 
> One of the tests in GraphDescriptionTest illustrates simple usage,
>> thus:
> 
> Neo

Re: [Neo4j] py2neo - GEOFF enhancements

[Nigel Small]

Peter: I am happy with the current state of the neo4j-geoff code so feel it
should be stable enough to adopt when you wish to do so. I have also made a
couple of recent updates to the documentation, most notably the GEOFF.md
file.

Cheers

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 
LinkedIn: http://uk.linkedin.com/in/nigelsmall



On 29 November 2011 23:33, Michael Hunger
wrote:

> #1 Thanks
> #2 You're probably right
>
> #3 You can do the index lookup outside and pass in the IndexHits as
> being and Iterator
> #3 I rather thought of {name} for |people| -> {name: {hook}} as a shortcut
> for that
>
> Michael
>
> But #2 and #3 are probably overkill anyway.
>
> Cheers
>
> Michael
>
> Am 29.11.2011 um 23:59 schrieb Nigel Small:
>
> > Hi Michael
> >
> >> Probably better to just return the full map and let the client code deal
> > with it ? (If it isn't interested it would either just ignore the return
> > result or discard it quickly).
> > Done. Now works as:
> >
> > Map entities =
> GEOFFLoader.loadIntoNeo4j(reader,
> > db, hooks);
> > Node nodeFoo = (Node) entities.get("(foo)");
> > Node nodeBar = (Node) entities.get("(bar)");
> >
> >> Intention behind longs, is when I get them from an external source then
> > they can be used to be look up nodes during import.
> > This can be done but not sure it's the right place... I'm cautious about
> > using IDs directly as they aren't very portable. Also, it's not intuitive
> > whether an ID is for a node or relationship. Would like to get a few
> votes
> > on this - I'm happy to be outvoted if the consensus is to do it!
> >
> >> Also can hooks be used for index lookups? (Just asking)
> > Are you thinking of something like "{People:name=bert}"? If so, this is
> > quite a distance from where we are currently since every token can only
> > refer to a single entity, whereas an index lookup could return multiple
> > results.
> >
> > 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 
> > LinkedIn: http://uk.linkedin.com/in/nigelsmall
> >
> >
> >
> > On 29 November 2011 22:09, Michael Hunger
> > wrote:
> >
> >> Hmm good question, that means the namespace keeps everything around
> until
> >> it is gc'ed ?
> >>
> >> Probably better to just return the full map and let the client code deal
> >> with it ? (If it isn't interested it would either just ignore the return
> >> result or discard it quickly).
> >>
> >> Intention behind longs, is when I get them from an external source then
> >> they can be used to be look up nodes during import.
> >>
> >> Also can hooks be used for index lookups? (Just asking)
> >>
> >> Thanks a lot
> >>
> >> Michael
> >>
> >> Am 29.11.2011 um 22:58 schrieb Nigel Small:
> >>
> >>> Hi Michael
> >>>
> >>> Doesn't handle iterables (yet) but should be quite easy to add in. What
> >>> purpose did you have behind longs?
> >>>
> >>> I've just committed a few new methods allowing the Neo4jNamespace
> >> returned
> >>> from a loadIntoNeo4j call to be used to retrieve new entities by name
> >> (or a
> >>> map of such). The new methods are:
> >>>
> >>> public Node getPreexistingNode(String name)
> >>> public Map getPreexistingNodes(String... names)
> >>> public Node getNewlyCreatedNode(String name)
> >>> public Map getNewlyCreatedNodes(String... names)
> >>> public Relationship getPreexistingRelationship(String name)
> >>> public Map getPreexistingRelationships(String...
> >>> names)
> >>> public Relationship getNewlyCreatedRelationship(String name)
> >>> public Map getNewlyCreatedRelationships(String...
> >>> names)
> >>>
> >>> One of the tests in GraphDescriptionTest illustrates simple usage,
> thus:
> >>>
> >>> Neo4jNamespace ns = GEOFFLoader.loadIntoNeo4j(reader, db, hooks);
> >>> Node nodeFoo = ns.getNewlyCreatedNode("foo");
> >>> Node nodeBar = ns.getNewlyCreatedNode("bar");
> >>>
> >>> Hope this helps - I'll have a play with iterables next.
> >>>
> >>> Cheers
> >>>
> >>> 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 
> >>> LinkedIn: http://uk.linkedin.com/in/nigelsmall
> >>>
> >>>
> >>>
> >>> On 29 November 2011 15:58, Michael Hunger
> >>> wrote:
> >>>
>  does it also handle iterables of nodes/rels (and probably Longs?)
> 
>  while thinking about it
>  it would be great if the loader could also return a map of variables
> of
>  the things generated to be used further in processing
> 
>  that could also interesting for cascading  geoff and/or cypher
> 
>  cool stuff big thanks
> 
>  michael
> >>

Re: [Neo4j] py2neo - GEOFF enhancements

[Michael Hunger]

#1 Thanks
#2 You're probably right

#3 You can do the index lookup outside and pass in the IndexHits as being 
and Iterator
#3 I rather thought of {name} for |people| -> {name: {hook}} as a shortcut for 
that

Michael

But #2 and #3 are probably overkill anyway.

Cheers

Michael

Am 29.11.2011 um 23:59 schrieb Nigel Small:

> Hi Michael
> 
>> Probably better to just return the full map and let the client code deal
> with it ? (If it isn't interested it would either just ignore the return
> result or discard it quickly).
> Done. Now works as:
> 
> Map entities = GEOFFLoader.loadIntoNeo4j(reader,
> db, hooks);
> Node nodeFoo = (Node) entities.get("(foo)");
> Node nodeBar = (Node) entities.get("(bar)");
> 
>> Intention behind longs, is when I get them from an external source then
> they can be used to be look up nodes during import.
> This can be done but not sure it's the right place... I'm cautious about
> using IDs directly as they aren't very portable. Also, it's not intuitive
> whether an ID is for a node or relationship. Would like to get a few votes
> on this - I'm happy to be outvoted if the consensus is to do it!
> 
>> Also can hooks be used for index lookups? (Just asking)
> Are you thinking of something like "{People:name=bert}"? If so, this is
> quite a distance from where we are currently since every token can only
> refer to a single entity, whereas an index lookup could return multiple
> results.
> 
> 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 
> LinkedIn: http://uk.linkedin.com/in/nigelsmall
> 
> 
> 
> On 29 November 2011 22:09, Michael Hunger
> wrote:
> 
>> Hmm good question, that means the namespace keeps everything around until
>> it is gc'ed ?
>> 
>> Probably better to just return the full map and let the client code deal
>> with it ? (If it isn't interested it would either just ignore the return
>> result or discard it quickly).
>> 
>> Intention behind longs, is when I get them from an external source then
>> they can be used to be look up nodes during import.
>> 
>> Also can hooks be used for index lookups? (Just asking)
>> 
>> Thanks a lot
>> 
>> Michael
>> 
>> Am 29.11.2011 um 22:58 schrieb Nigel Small:
>> 
>>> Hi Michael
>>> 
>>> Doesn't handle iterables (yet) but should be quite easy to add in. What
>>> purpose did you have behind longs?
>>> 
>>> I've just committed a few new methods allowing the Neo4jNamespace
>> returned
>>> from a loadIntoNeo4j call to be used to retrieve new entities by name
>> (or a
>>> map of such). The new methods are:
>>> 
>>> public Node getPreexistingNode(String name)
>>> public Map getPreexistingNodes(String... names)
>>> public Node getNewlyCreatedNode(String name)
>>> public Map getNewlyCreatedNodes(String... names)
>>> public Relationship getPreexistingRelationship(String name)
>>> public Map getPreexistingRelationships(String...
>>> names)
>>> public Relationship getNewlyCreatedRelationship(String name)
>>> public Map getNewlyCreatedRelationships(String...
>>> names)
>>> 
>>> One of the tests in GraphDescriptionTest illustrates simple usage, thus:
>>> 
>>> Neo4jNamespace ns = GEOFFLoader.loadIntoNeo4j(reader, db, hooks);
>>> Node nodeFoo = ns.getNewlyCreatedNode("foo");
>>> Node nodeBar = ns.getNewlyCreatedNode("bar");
>>> 
>>> Hope this helps - I'll have a play with iterables next.
>>> 
>>> Cheers
>>> 
>>> 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 
>>> LinkedIn: http://uk.linkedin.com/in/nigelsmall
>>> 
>>> 
>>> 
>>> On 29 November 2011 15:58, Michael Hunger
>>> wrote:
>>> 
 does it also handle iterables of nodes/rels (and probably Longs?)
 
 while thinking about it
 it would be great if the loader could also return a map of variables of
 the things generated to be used further in processing
 
 that could also interesting for cascading  geoff and/or cypher
 
 cool stuff big thanks
 
 michael
 
 mobile mail please excuse brevity and typos
 
 Am 29.11.2011 um 16:18 schrieb Peter Neubauer <
 peter.neuba...@neotechnology.com>:
 
> That sounds great! Let me know when you are stable, and I will see if
> I can do some more on the server plugin side, so we can shoot in
> things there!
> 
> 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 Mon, Nov 28, 2

Re: [Neo4j] py2neo - GEOFF enhancements

[Nigel Small]

Hi Michael

>Probably better to just return the full map and let the client code deal
with it ? (If it isn't interested it would either just ignore the return
result or discard it quickly).
Done. Now works as:

Map entities = GEOFFLoader.loadIntoNeo4j(reader,
db, hooks);
Node nodeFoo = (Node) entities.get("(foo)");
Node nodeBar = (Node) entities.get("(bar)");

>Intention behind longs, is when I get them from an external source then
they can be used to be look up nodes during import.
This can be done but not sure it's the right place... I'm cautious about
using IDs directly as they aren't very portable. Also, it's not intuitive
whether an ID is for a node or relationship. Would like to get a few votes
on this - I'm happy to be outvoted if the consensus is to do it!

>Also can hooks be used for index lookups? (Just asking)
Are you thinking of something like "{People:name=bert}"? If so, this is
quite a distance from where we are currently since every token can only
refer to a single entity, whereas an index lookup could return multiple
results.

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 
LinkedIn: http://uk.linkedin.com/in/nigelsmall



On 29 November 2011 22:09, Michael Hunger
wrote:

> Hmm good question, that means the namespace keeps everything around until
> it is gc'ed ?
>
> Probably better to just return the full map and let the client code deal
> with it ? (If it isn't interested it would either just ignore the return
> result or discard it quickly).
>
> Intention behind longs, is when I get them from an external source then
> they can be used to be look up nodes during import.
>
> Also can hooks be used for index lookups? (Just asking)
>
> Thanks a lot
>
> Michael
>
> Am 29.11.2011 um 22:58 schrieb Nigel Small:
>
> > Hi Michael
> >
> > Doesn't handle iterables (yet) but should be quite easy to add in. What
> > purpose did you have behind longs?
> >
> > I've just committed a few new methods allowing the Neo4jNamespace
> returned
> > from a loadIntoNeo4j call to be used to retrieve new entities by name
> (or a
> > map of such). The new methods are:
> >
> > public Node getPreexistingNode(String name)
> > public Map getPreexistingNodes(String... names)
> > public Node getNewlyCreatedNode(String name)
> > public Map getNewlyCreatedNodes(String... names)
> > public Relationship getPreexistingRelationship(String name)
> > public Map getPreexistingRelationships(String...
> > names)
> > public Relationship getNewlyCreatedRelationship(String name)
> > public Map getNewlyCreatedRelationships(String...
> > names)
> >
> > One of the tests in GraphDescriptionTest illustrates simple usage, thus:
> >
> > Neo4jNamespace ns = GEOFFLoader.loadIntoNeo4j(reader, db, hooks);
> > Node nodeFoo = ns.getNewlyCreatedNode("foo");
> > Node nodeBar = ns.getNewlyCreatedNode("bar");
> >
> > Hope this helps - I'll have a play with iterables next.
> >
> > Cheers
> >
> > 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 
> > LinkedIn: http://uk.linkedin.com/in/nigelsmall
> >
> >
> >
> > On 29 November 2011 15:58, Michael Hunger
> > wrote:
> >
> >> does it also handle iterables of nodes/rels (and probably Longs?)
> >>
> >> while thinking about it
> >> it would be great if the loader could also return a map of variables of
> >> the things generated to be used further in processing
> >>
> >> that could also interesting for cascading  geoff and/or cypher
> >>
> >> cool stuff big thanks
> >>
> >> michael
> >>
> >> mobile mail please excuse brevity and typos
> >>
> >> Am 29.11.2011 um 16:18 schrieb Peter Neubauer <
> >> peter.neuba...@neotechnology.com>:
> >>
> >>> That sounds great! Let me know when you are stable, and I will see if
> >>> I can do some more on the server plugin side, so we can shoot in
> >>> things there!
> >>>
> >>> 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 Mon, Nov 28, 2011 at 9:52 PM, Nigel Small 
> >> wrote:
>  Hi Peter
> 
>  Bulk of the work is now done on the Java version of the GEOFF
> >> enhancements.
>  There have been some significant changes to the classes and a number
> of
>  extra tests inserted. The signature of the load method has now been
>  extended to:
> 
>  public static Neo4jNamespace loadIntoNeo4j(Reader reader,
>  GraphDatabaseService graphDB, Map
>  hooks)
> 

Re: [Neo4j] py2neo - GEOFF enhancements

[Michael Hunger]

Hmm good question, that means the namespace keeps everything around until it is 
gc'ed ?

Probably better to just return the full map and let the client code deal with 
it ? (If it isn't interested it would either just ignore the return result or 
discard it quickly).

Intention behind longs, is when I get them from an external source then they 
can be used to be look up nodes during import.

Also can hooks be used for index lookups? (Just asking)

Thanks a lot

Michael

Am 29.11.2011 um 22:58 schrieb Nigel Small:

> Hi Michael
> 
> Doesn't handle iterables (yet) but should be quite easy to add in. What
> purpose did you have behind longs?
> 
> I've just committed a few new methods allowing the Neo4jNamespace returned
> from a loadIntoNeo4j call to be used to retrieve new entities by name (or a
> map of such). The new methods are:
> 
> public Node getPreexistingNode(String name)
> public Map getPreexistingNodes(String... names)
> public Node getNewlyCreatedNode(String name)
> public Map getNewlyCreatedNodes(String... names)
> public Relationship getPreexistingRelationship(String name)
> public Map getPreexistingRelationships(String...
> names)
> public Relationship getNewlyCreatedRelationship(String name)
> public Map getNewlyCreatedRelationships(String...
> names)
> 
> One of the tests in GraphDescriptionTest illustrates simple usage, thus:
> 
> Neo4jNamespace ns = GEOFFLoader.loadIntoNeo4j(reader, db, hooks);
> Node nodeFoo = ns.getNewlyCreatedNode("foo");
> Node nodeBar = ns.getNewlyCreatedNode("bar");
> 
> Hope this helps - I'll have a play with iterables next.
> 
> Cheers
> 
> 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 
> LinkedIn: http://uk.linkedin.com/in/nigelsmall
> 
> 
> 
> On 29 November 2011 15:58, Michael Hunger
> wrote:
> 
>> does it also handle iterables of nodes/rels (and probably Longs?)
>> 
>> while thinking about it
>> it would be great if the loader could also return a map of variables of
>> the things generated to be used further in processing
>> 
>> that could also interesting for cascading  geoff and/or cypher
>> 
>> cool stuff big thanks
>> 
>> michael
>> 
>> mobile mail please excuse brevity and typos
>> 
>> Am 29.11.2011 um 16:18 schrieb Peter Neubauer <
>> peter.neuba...@neotechnology.com>:
>> 
>>> That sounds great! Let me know when you are stable, and I will see if
>>> I can do some more on the server plugin side, so we can shoot in
>>> things there!
>>> 
>>> 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 Mon, Nov 28, 2011 at 9:52 PM, Nigel Small 
>> wrote:
 Hi Peter
 
 Bulk of the work is now done on the Java version of the GEOFF
>> enhancements.
 There have been some significant changes to the classes and a number of
 extra tests inserted. The signature of the load method has now been
 extended to:
 
 public static Neo4jNamespace loadIntoNeo4j(Reader reader,
 GraphDatabaseService graphDB, Map
 hooks)
 
 ...where the final parameter expects a Map full of names
 Nodes/Relationships which may then be referenced from within the GEOFF
 source.
 
 Let me know how you get on and give me a shout if I've forgotten
>> anything
 :-)
 
 Cheers
 
 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 
 LinkedIn: http://uk.linkedin.com/in/nigelsmall
 
 
 
 On 23 November 2011 10:12, Peter Neubauer  wrote:
 
> Looks great to me Nigel! I think this is a very good first step on
> parameters. Let me know when you are done with the Java code, would
> like to bring this into the @Graph annotations after our next
> milestone release, 1.6.M01.
> 
> /peter
> 
> On Tue, Nov 22, 2011 at 10:14 PM, Nigel Small 
> wrote:
>> Hi all
>> 
>> I have just completed a set of GEOFF enhancements within py2neo (as
>> yet
>> only available from GitHub). Named parameters (hooks) and composite
>> descriptors are now supported, please see the following sample file
>> for
> an
>> illustration of the new capabilites:
>> 
>> 
> 
>> https://github.com/nigelsmall/py2neo/blob/master/src/py2neo-examples/geoff/node-hooks.geoff
>> 
>> In addition, a change has been made for index entries to use |foo|
>> syntax
>> instead of {foo} syntax as prev

Re: [Neo4j] py2neo - GEOFF enhancements

[Nigel Small]

Hi Michael

Doesn't handle iterables (yet) but should be quite easy to add in. What
purpose did you have behind longs?

I've just committed a few new methods allowing the Neo4jNamespace returned
from a loadIntoNeo4j call to be used to retrieve new entities by name (or a
map of such). The new methods are:

public Node getPreexistingNode(String name)
public Map getPreexistingNodes(String... names)
public Node getNewlyCreatedNode(String name)
public Map getNewlyCreatedNodes(String... names)
public Relationship getPreexistingRelationship(String name)
public Map getPreexistingRelationships(String...
names)
public Relationship getNewlyCreatedRelationship(String name)
public Map getNewlyCreatedRelationships(String...
names)

One of the tests in GraphDescriptionTest illustrates simple usage, thus:

Neo4jNamespace ns = GEOFFLoader.loadIntoNeo4j(reader, db, hooks);
Node nodeFoo = ns.getNewlyCreatedNode("foo");
Node nodeBar = ns.getNewlyCreatedNode("bar");

Hope this helps - I'll have a play with iterables next.

Cheers

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 
LinkedIn: http://uk.linkedin.com/in/nigelsmall



On 29 November 2011 15:58, Michael Hunger
wrote:

> does it also handle iterables of nodes/rels (and probably Longs?)
>
> while thinking about it
> it would be great if the loader could also return a map of variables of
> the things generated to be used further in processing
>
> that could also interesting for cascading  geoff and/or cypher
>
> cool stuff big thanks
>
> michael
>
> mobile mail please excuse brevity and typos
>
> Am 29.11.2011 um 16:18 schrieb Peter Neubauer <
> peter.neuba...@neotechnology.com>:
>
> > That sounds great! Let me know when you are stable, and I will see if
> > I can do some more on the server plugin side, so we can shoot in
> > things there!
> >
> > 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 Mon, Nov 28, 2011 at 9:52 PM, Nigel Small 
> wrote:
> >> Hi Peter
> >>
> >> Bulk of the work is now done on the Java version of the GEOFF
> enhancements.
> >> There have been some significant changes to the classes and a number of
> >> extra tests inserted. The signature of the load method has now been
> >> extended to:
> >>
> >> public static Neo4jNamespace loadIntoNeo4j(Reader reader,
> >> GraphDatabaseService graphDB, Map
> >> hooks)
> >>
> >> ...where the final parameter expects a Map full of names
> >> Nodes/Relationships which may then be referenced from within the GEOFF
> >> source.
> >>
> >> Let me know how you get on and give me a shout if I've forgotten
> anything
> >> :-)
> >>
> >> Cheers
> >>
> >> 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 
> >> LinkedIn: http://uk.linkedin.com/in/nigelsmall
> >>
> >>
> >>
> >> On 23 November 2011 10:12, Peter Neubauer  wrote:
> >>
> >>> Looks great to me Nigel! I think this is a very good first step on
> >>> parameters. Let me know when you are done with the Java code, would
> >>> like to bring this into the @Graph annotations after our next
> >>> milestone release, 1.6.M01.
> >>>
> >>> /peter
> >>>
> >>> On Tue, Nov 22, 2011 at 10:14 PM, Nigel Small 
> >>> wrote:
>  Hi all
> 
>  I have just completed a set of GEOFF enhancements within py2neo (as
> yet
>  only available from GitHub). Named parameters (hooks) and composite
>  descriptors are now supported, please see the following sample file
> for
> >>> an
>  illustration of the new capabilites:
> 
> 
> >>>
> https://github.com/nigelsmall/py2neo/blob/master/src/py2neo-examples/geoff/node-hooks.geoff
> 
>  In addition, a change has been made for index entries to use |foo|
> syntax
>  instead of {foo} syntax as previously (although the old syntax will
> still
>  work for now).
> 
>  Finally, there is a new wiki page detailing the current format in
> full:
> 
>  https://github.com/nigelsmall/py2neo/wiki/GEOFF
> 
>  I will now start planning the set of work required for the neo4j-geoff
>  project to bring that up to the same level.
> 
>  Cheers
> 
>  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 
>  LinkedIn: http://uk.lin

Re: [Neo4j] py2neo - GEOFF enhancements

[Michael Hunger]

does it also handle iterables of nodes/rels (and probably Longs?)

while thinking about it
it would be great if the loader could also return a map of variables of the 
things generated to be used further in processing

that could also interesting for cascading  geoff and/or cypher

cool stuff big thanks 

michael

mobile mail please excuse brevity and typos

Am 29.11.2011 um 16:18 schrieb Peter Neubauer 
:

> That sounds great! Let me know when you are stable, and I will see if
> I can do some more on the server plugin side, so we can shoot in
> things there!
> 
> 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 Mon, Nov 28, 2011 at 9:52 PM, Nigel Small  wrote:
>> Hi Peter
>> 
>> Bulk of the work is now done on the Java version of the GEOFF enhancements.
>> There have been some significant changes to the classes and a number of
>> extra tests inserted. The signature of the load method has now been
>> extended to:
>> 
>> public static Neo4jNamespace loadIntoNeo4j(Reader reader,
>> GraphDatabaseService graphDB, Map
>> hooks)
>> 
>> ...where the final parameter expects a Map full of names
>> Nodes/Relationships which may then be referenced from within the GEOFF
>> source.
>> 
>> Let me know how you get on and give me a shout if I've forgotten anything
>> :-)
>> 
>> Cheers
>> 
>> 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 
>> LinkedIn: http://uk.linkedin.com/in/nigelsmall
>> 
>> 
>> 
>> On 23 November 2011 10:12, Peter Neubauer  wrote:
>> 
>>> Looks great to me Nigel! I think this is a very good first step on
>>> parameters. Let me know when you are done with the Java code, would
>>> like to bring this into the @Graph annotations after our next
>>> milestone release, 1.6.M01.
>>> 
>>> /peter
>>> 
>>> On Tue, Nov 22, 2011 at 10:14 PM, Nigel Small 
>>> wrote:
 Hi all
 
 I have just completed a set of GEOFF enhancements within py2neo (as yet
 only available from GitHub). Named parameters (hooks) and composite
 descriptors are now supported, please see the following sample file for
>>> an
 illustration of the new capabilites:
 
 
>>> https://github.com/nigelsmall/py2neo/blob/master/src/py2neo-examples/geoff/node-hooks.geoff
 
 In addition, a change has been made for index entries to use |foo| syntax
 instead of {foo} syntax as previously (although the old syntax will still
 work for now).
 
 Finally, there is a new wiki page detailing the current format in full:
 
 https://github.com/nigelsmall/py2neo/wiki/GEOFF
 
 I will now start planning the set of work required for the neo4j-geoff
 project to bring that up to the same level.
 
 Cheers
 
 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 
 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 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 - GEOFF enhancements

[Peter Neubauer]

That sounds great! Let me know when you are stable, and I will see if
I can do some more on the server plugin side, so we can shoot in
things there!

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 Mon, Nov 28, 2011 at 9:52 PM, Nigel Small  wrote:
> Hi Peter
>
> Bulk of the work is now done on the Java version of the GEOFF enhancements.
> There have been some significant changes to the classes and a number of
> extra tests inserted. The signature of the load method has now been
> extended to:
>
> public static Neo4jNamespace loadIntoNeo4j(Reader reader,
> GraphDatabaseService graphDB, Map
> hooks)
>
> ...where the final parameter expects a Map full of names
> Nodes/Relationships which may then be referenced from within the GEOFF
> source.
>
> Let me know how you get on and give me a shout if I've forgotten anything
> :-)
>
> Cheers
>
> 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 
> LinkedIn: http://uk.linkedin.com/in/nigelsmall
>
>
>
> On 23 November 2011 10:12, Peter Neubauer  wrote:
>
>> Looks great to me Nigel! I think this is a very good first step on
>> parameters. Let me know when you are done with the Java code, would
>> like to bring this into the @Graph annotations after our next
>> milestone release, 1.6.M01.
>>
>> /peter
>>
>> On Tue, Nov 22, 2011 at 10:14 PM, Nigel Small 
>> wrote:
>> > Hi all
>> >
>> > I have just completed a set of GEOFF enhancements within py2neo (as yet
>> > only available from GitHub). Named parameters (hooks) and composite
>> > descriptors are now supported, please see the following sample file for
>> an
>> > illustration of the new capabilites:
>> >
>> >
>> https://github.com/nigelsmall/py2neo/blob/master/src/py2neo-examples/geoff/node-hooks.geoff
>> >
>> > In addition, a change has been made for index entries to use |foo| syntax
>> > instead of {foo} syntax as previously (although the old syntax will still
>> > work for now).
>> >
>> > Finally, there is a new wiki page detailing the current format in full:
>> >
>> > https://github.com/nigelsmall/py2neo/wiki/GEOFF
>> >
>> > I will now start planning the set of work required for the neo4j-geoff
>> > project to bring that up to the same level.
>> >
>> > Cheers
>> >
>> > 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 
>> > 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 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 - GEOFF enhancements

[Nigel Small]

Hi Peter

Bulk of the work is now done on the Java version of the GEOFF enhancements.
There have been some significant changes to the classes and a number of
extra tests inserted. The signature of the load method has now been
extended to:

public static Neo4jNamespace loadIntoNeo4j(Reader reader,
GraphDatabaseService graphDB, Map
hooks)

...where the final parameter expects a Map full of names
Nodes/Relationships which may then be referenced from within the GEOFF
source.

Let me know how you get on and give me a shout if I've forgotten anything
:-)

Cheers

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 
LinkedIn: http://uk.linkedin.com/in/nigelsmall



On 23 November 2011 10:12, Peter Neubauer  wrote:

> Looks great to me Nigel! I think this is a very good first step on
> parameters. Let me know when you are done with the Java code, would
> like to bring this into the @Graph annotations after our next
> milestone release, 1.6.M01.
>
> /peter
>
> On Tue, Nov 22, 2011 at 10:14 PM, Nigel Small 
> wrote:
> > Hi all
> >
> > I have just completed a set of GEOFF enhancements within py2neo (as yet
> > only available from GitHub). Named parameters (hooks) and composite
> > descriptors are now supported, please see the following sample file for
> an
> > illustration of the new capabilites:
> >
> >
> https://github.com/nigelsmall/py2neo/blob/master/src/py2neo-examples/geoff/node-hooks.geoff
> >
> > In addition, a change has been made for index entries to use |foo| syntax
> > instead of {foo} syntax as previously (although the old syntax will still
> > work for now).
> >
> > Finally, there is a new wiki page detailing the current format in full:
> >
> > https://github.com/nigelsmall/py2neo/wiki/GEOFF
> >
> > I will now start planning the set of work required for the neo4j-geoff
> > project to bring that up to the same level.
> >
> > Cheers
> >
> > 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 
> > 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 mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user

Re: [Neo4j] py2neo - GEOFF enhancements

[Peter Neubauer]

Looks great to me Nigel! I think this is a very good first step on
parameters. Let me know when you are done with the Java code, would
like to bring this into the @Graph annotations after our next
milestone release, 1.6.M01.

/peter

On Tue, Nov 22, 2011 at 10:14 PM, Nigel Small  wrote:
> Hi all
>
> I have just completed a set of GEOFF enhancements within py2neo (as yet
> only available from GitHub). Named parameters (hooks) and composite
> descriptors are now supported, please see the following sample file for an
> illustration of the new capabilites:
>
> https://github.com/nigelsmall/py2neo/blob/master/src/py2neo-examples/geoff/node-hooks.geoff
>
> In addition, a change has been made for index entries to use |foo| syntax
> instead of {foo} syntax as previously (although the old syntax will still
> work for now).
>
> Finally, there is a new wiki page detailing the current format in full:
>
> https://github.com/nigelsmall/py2neo/wiki/GEOFF
>
> I will now start planning the set of work required for the neo4j-geoff
> project to bring that up to the same level.
>
> Cheers
>
> 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 
> 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 - GEOFF enhancements

[Nigel Small]

Hi all

I have just completed a set of GEOFF enhancements within py2neo (as yet
only available from GitHub). Named parameters (hooks) and composite
descriptors are now supported, please see the following sample file for an
illustration of the new capabilites:

https://github.com/nigelsmall/py2neo/blob/master/src/py2neo-examples/geoff/node-hooks.geoff

In addition, a change has been made for index entries to use |foo| syntax
instead of {foo} syntax as previously (although the old syntax will still
work for now).

Finally, there is a new wiki page detailing the current format in full:

https://github.com/nigelsmall/py2neo/wiki/GEOFF

I will now start planning the set of work required for the neo4j-geoff
project to bring that up to the same level.

Cheers

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 
LinkedIn: http://uk.linkedin.com/in/nigelsmall
___
Neo4j mailing list
User@lists.neo4j.org
https://lists.neo4j.org/mailman/listinfo/user