neo4j combine multiple relationship and create a new one on the fly

[nitingar]

I am new to the neo4j world. I have a situation where i have multiple relationship b/w nodes, these relationship has properties. Now i need to combine these relationship into 1 relationship and sum up there property.

For example NodeA---->NodeB with R1(count=2),R2 (count=4),R2 (count=1),R4(count=10)

now i need to combine these into one relationship say newR NodeA--->NodeB with newR(count=17).

Would prefer if this is created as a temp relationship, so that its not persisted inthe databse.

[Joel]

What is your goal? How to approach this likely depends on what you plan to do after this...

Technically speaking, it isn't possible to create a relationship that isn't persisted in the database, however

• you could sum the R on the fly inside a query, and then use the result
• you are free to create new relationships and delete them later. i.e. create the new relationship with a different name so you can easily reference them for use, and deletion later...
• if you plan to use GDS algorithms on the new graph, perhaps you want to explore creating an in-memory (new) graph, these are by definition temporary in nature, but what you can do with in-memory graphs is limited mostly to running GDS functions on them. If you want to explore this option, I'd suggest perhaps starting with a Cypher Projection at first, it is a bit easier to understand quickly.

[nitingar]

Hi Joe,

Thanks for the reply.
My goal is to build a run time topology around the access pattern of the complex application. For that purpose i model my graph db something like this:
Every svc will act as an node, thinking of creating edges with daily access patter.
So for day1 svc1-rD1-svc2 , svc2-rD1-sv3, sv3-rD1-sv1
So for day2 svc1-rD2-svc3 , svc2-rD2-sv3, sv3-rD2-sv1

So with above data model i can store each day access pattern.

But my client might want to look the access pattern on the monthly basis, in tht case i need to merge each day access patter and come up with the monthly access pattern.