Cannot create properties on relationships about blueprint41 HOT 7 CLOSED

The choice not to support properties on relations (yet) was made for the following reasons:

1. Properties on relationships are in general inefficient because they can not be indexed on Neo4j.
2. In a graph to object model mapping, relationships are translated to "collections of node objects". However, there seems no obvious place to map the property of those relations to. Unless if we make a "collection of relations objects".
3. "relation objects" would look exactly identical to "node objects" in your C# code
4. If you're not invested to the idea of storing properties on relations just for the sake of it, (we think) there is no advantage from a code point of view to do it.
5. If you are invested to the idea of storing properties on relations, in most cases, your queries will run slower due to indexing not being supported.

However, we do acknowledge that it is a short coming and would prefer to support the feature.
If you can come up with any reason (other than being invested in the idea of it, just for the sake of it) to add the feature and/or can think of a good/nice/clean way how relationship properties should be mapped to collections/lists (the OO variant of a relation), we are very interested to hear (and implement) it!

from blueprint41.

Those reasons make sense to me. This is the first project I've really used a graph database extensively for so I wasn't aware of the indexing issues. Definitely not invested either way so I don't mind using a node for those properties. I appreciate the quick response and the awesome work that's gone into this - it's made our integration with Neo4j really smooth and easy. : )

from blueprint41.

@circles-arrows

Thanks for clarification, suppose I have such scenario:

TwitterUser node and FOLLOWS relation to other TwitterUser.

So I would like to know when FOLLOW relation was detected and thus
was previously saving this timestamp on relation itself, but as I know discovered
this library I am quite confused on how I could replicate this with nodes.

Should I achieve the same result by converting FOLLOWS relation to Node and having
something (u:TwitterUser)-[:PERFORMS]->(f:FOLLOW) and then save timetamp on FOLLOW node?

from blueprint41.

In bluerpint41 we automatically make a CreationDate property on each relationship that is saved in the graph. If you want to only query the relationship, you can access this CreationDate property from a (type-safe) query. In the CRUD generated classes this property is not accessible though.

Now to get to your specific situation:

• You could keep the timetamp (maybe you need to rename the property though) IF you only need to access the timestamp during querying. (Or if you don't need to access it at all..)
• If you need more properties on the relationship or if you need more control when doing CRUD operations I would indeed go with the FOLLOW node like you propose. The only issue with this solution I can think of is that the querying of repeated relations (followers of followers of followers, etc like: [FOLLOWS1..6]) will not work that simple anymore.

If neither option works for you, you could come up with some ideas how Blueprint41 could work so it would solve your problem. If it's something that solves the properties on relationship problem, we're more than happy to prioritize the change and make that happen.

from blueprint41.

@circles-arrows ,
The APOC path finding algorithms use a "weighted relationship" methodology for path calculation.

https://neo4j.com/docs/graph-data-science/current/algorithms/pathfinding/

Note the "relationshipWeightProperty" used in the Dijkstra algorithm.

https://neo4j.com/docs/graph-data-science/current/algorithms/dijkstra-source-target/

For us, path finding is one of the key capabilities we hope to get from our Neo4j implementation.

In our case, we plan to run the path finding algorithm using one of 3 dimension: Cost, Time, or Balance. This would require storing 3 properties on the relationship:

• costScore
• timeScore
• balanceScore

I haven't been able to find any alternative approach in the APOC algorithms. For example, I haven't found a path finding algorithm that can pull the scores from node properties instead of relationship properties.

Do you have any advice on how we might handle these relationship properties, from a blueprint41 ORM perspective? Any approach that might yield a successful implementation?

from blueprint41.

@RobHudson72

Nice example Rob!

We already decided a month or so ago that we should take the time for a brainstorm session to really solve this issue. With your feedback the other day we decided this is the moment.
We did another brainstorm session and, after letting it sink in for several years, this time around came up with a somewhat elegant solution.

We will schedule & prioritize this change, since this has been pending for a long time already.

If you want to help out with testing, giving early feedback or just be in the loop, please send an email to:

from blueprint41.

@circles-arrows this is excellent news! I will definitely be interested in participating in testing! I will shoot you an email today!

from blueprint41.