Relationships

[Chris Skardon]

Hullo,

As part of the Cypher 2.0 upgrade, are things like 'Relationship' (as in the actual class) being deprecated?  In examples you're doing things like:

graphClient.Cypher
    .Match("(invitee:User)")
    .Where((User invitee) => invitee.Id == 123)
    .Create("invitee-[:INVITED]->(invited:User {newUser})")
    .WithParam("newUser", newUser)
    .ExecuteWithoutResults();

Is this the preferred manner here on in? 

Cheers!

[Jacqui Read]

I would be interested in the answer to this. I am just starting with Neo4j and Neo4jClient, and I want to make sure I am doing the right thing.

Examples I am looking at have the relationships defined as classes, so if I should not be doing this I would like to know.

Looking at the example I don't see how having the relationships defined as classes affects it, so maybe they are not required any more. How would this example have been written before 2.0?

All the best,

Jacqui

[Tatham Oddie]

Well and truly.

 

Basically, your object model should just be POCOs that represent your data structure (like the User class in the examples).

 

All of the Node<T>, Relationship<T>, RelationshipInstance<T> stuff will go away.

 

--

Tatham Oddie

--
You received this message because you are subscribed to the Google Groups "Neo4jClient" group.
To unsubscribe from this group and stop receiving emails from it, send an email to neo4jclient...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

[Chris Skardon]

OK - that's what I thought, with that in mind - what is the thinking for Paths for the near future? 

The neo4j documentation doesn't explicitly say they're getting rid of it, and the docs on the milestone do show some usages of it, but I think that's either oversight or something else...

I'd prefer to avoid using Relationship etc if it's not required and will be deprecated, so my question would be how to get 'subgraphs' i.e. if I have : A-B-C-D and I have a start point of 'B' and steps of '2' I would get 'B-C-D', I'm currently using paths to achieve this, is there a better / preferred way?

Cheers

Chris

[Craig Brett]

If the Relationship class et al is on the way out, what's the situation on using paths? And how about relationship properties? Would you have to manually map that into your desired POCO? Or is/will there be a better way?

With this happening, it will clean up my code a lot, I'm just curious to know how it will go.

[Chris Skardon]

Relationship properties are handled in POCOs, so:

var q = new CypherFluentQuery(gc)

    .Match("(n:Blah)-[r:REL]->(o:Blah)")

    .Return(r => r.As<SimpleRelationship>());

Would get you the properties for the relationship 'r'.

In terms of paths, I'm not sure the best approach for them, at the moment when I use paths is the only time I use 'Node<T>' as I need the references to evaluate the positions of the nodes on the path.

On 10 January 2014 09:22, Craig Brett <craig...@facebook.com> wrote:

If the Relationship class et al is on the way out, what's the situation on using paths? And how about relationship properties? Would you have to manually map that into your desired POCO? Or is/will there be a better way?

With this happening, it will clean up my code a lot, I'm just curious to know how it will go.

--

[Tatham Oddie]

I don’t really know how to handle paths nicely yet.

 

I’ll have to come up with a solution eventually.

 

For now, Node<T> and Relationship<T> will still be needed there.

 

Any ideas as to usage syntax and types are welcome. J

 

--

Tatham Oddie

[Chris Skardon]

Well - let's have a stab and get the conversation rolling :)

It's effectively a linked list right? a->b->c with a node and relationship for each element on the list (except the last), so something like:

class PathElement<TNode, TRel> { TNode Node { get;set;} TRel Relationship { get;set;} PathElement<TNode, TRel> Next {get;set;}}

buuut, what if the path goes across multiple different node/relationship types? 

so maybe something like

class PathElement { dynamic Node { get;set; } dynamic Relationship { get;set;} PathElement Next { get;set;}}

where calling the cypher is something like:

client.Cypher.Match("p = (a)-[*]->(c)").Return( p => p.As<PathElement>() )

Meh, I'm not sure really, just throwing the ideas around... I do think that dynamic may well be worth looking into even if it's just an extra return type (DynamicPathElement) - though not sure how to go about that at present.