SDN dynamic relationship

[Fredrik Hultin]

Hi, 

I tried to get a "dynamic" relationship using SDN but I cannot get it to work:

findByQuery("start me=node({nodeId}) match me-[:{type}]->other return other", Other.class, params)

Am I missing something or is this not the way to go? I could use getRelationshipTo(...) but I also thought it would work with cypher?

Cheers,

Fredrik 

[Fredrik Hultin]

Update, 

I cannot use getRelationshipTo I do not have the end node. I would like to get the end node by traversing from a node and giving the relationship type...

I would like to have something similar to this method:

public <T> T NodeBacked.getNodeForRelationship(String type, final Class<T> targetType) {...}

Cheers, 

Fredrik

[Andres Taylor]

Cypher does not currently support using parameters for relationship types. 

Andrés

[Fredrik Hultin]

Oh, ok.

What would be the recommended way to get a node via a generic relationship?

I solved it for now really easy by pre constructing the cypher query:

StringBuilder query = new StringBuilder();

        query.append("start me=node(").append(getId()).append(") ")

                .append("match me-[:").append(theType).append("]->x ")

                .append("return x");

and executed it via SDN:

findByQuery(query.toString(), TheClass.class, null)

This is a common strategy for handling sql in rdbms. What is the recommendations for neo4j? What is the difference from doing this and using the parameterized query in neo? Are there any performance implications?

If there are no major differences why not do as the rdbms and remove the parameterized queries and only accept complete queries and develop a pure string query building api since there is much support for this in java? Just asking ;)

Cheers,

Fredrik

[Michael Hunger]

Fredrik,

what would be the issue to use  template.getRelationships() ?

Or mix in the RelationshipOperationsRepository which has methods like:

    <R> R createRelationshipBetween(T start, Object end, Class<R> relationshipEntityClass, String relationshipType);

    <R> R createDuplicateRelationshipBetween(T start, Object end, Class<R> relationshipEntityClass, String relationshipType);

    <R> R getRelationshipBetween(T start, Object end, Class<R> relationshipEntityClass, String relationshipType);

    void deleteRelationshipBetween(T start, Object end, String type);

In general you wouldn't want to do that except for exceptions. As cypher queries are cached pre-parsed so you don't get the parsing penalty on each query. So parameters help to make queries look alike so that the cached value

will be reused.

There is a Cypher Java DSL which is also directly supported by SDN: https://github.com/neo4j/cypher-dsl

There is a CypherDSLRepository that you can mix in to your Repository to use.

[Andres Taylor]

On Wed, Jun 27, 2012 at 10:03 AM, Fredrik Hultin <fredrik...@collabra.se> wrote:

Oh, ok.

What would be the recommended way to get a node via a generic relationship?

I solved it for now really easy by pre constructing the cypher query:

StringBuilder query = new StringBuilder();

        query.append("start me=node(").append(getId()).append(") ")

                .append("match me-[:").append(theType).append("]->x ")

                .append("return x");

and executed it via SDN:

findByQuery(query.toString(), TheClass.class, null)

This is a common strategy for handling sql in rdbms. What is the recommendations for neo4j? What is the difference from doing this and using the parameterized query in neo? Are there any performance implications?

It's an anti-pattern in SQL as well. Parameterized queries protect you from injection attacks, doesn't force you to serialize data to strings to pass it to Neo4j, and makes it much easier to re-use execution plans (you save the cost of parsing the query, and producing an execution plan for it). If you can, you should use parameters when possible. 

The reason we don't have support for parameterized relationship types is because it changes the structure of your query. It's a little bit like making the table names in SQL something you can send in through parameters. Made little sense to me. I've since seen use cases where it makes sense to allow them as parameters - René's time line index comes to mind. Maybe it's time to change this? 

Andrés

[Fredrik Hultin]

Michael,

all those methods require the start and end node. In my case I do not have the end node for lookup only the start node and the "generic" relationship.

Example:

User

-- Loves 

   -- Hates

-- ANYTHING

to someone (where anything comes from the end user)

Query (again by the user)

"Who does User XX"?

Thx for the insight into cypher and the DSL. Will check it out ;)

Cheers,

Fredrik

[Fredrik Hultin]

@Andres

I totally agree about it being an anti-pattern and should be handled with care. Unfortunately it is oftenly used when the underlaying api does not allow you to do what you want to do as in this case.

When it comes to sending in the "names of the tables" I am not sure I agree. The structure in a rdbm is not something you like to display to your end users (mostly because they usually means nothing to the end user) while in the graph scenario it might just be.

In some occasions I am starting to think that it might be completely up to the end user to create and navigate the structure (as in the case of the user below), since the structure itself contains information. In other cases it needs to be controlled by code since that is the only way of ensuring a certain structure (system stuff for example).

I am still quite new to graph databases so I might be off here. 

Thx for clearing up the performance differences, soon we can compile your answers into that performance book ;)

Fredrik