Redisgraph: MATCH .. CREATE works, but MATCH .. MERGE has syntax error?

[davisford]

127.0.0.1:6379> GRAPH.QUERY authz "MATCH(o1:org {id: 1}) CREATE (p:posusers)-[:member]->(o1)"
1) (empty list or set)
2) 1) Labels added: 1
   2) Nodes created: 1
   3) Relationships created: 1
   4) "Query internal execution time: 0.236034 milliseconds"

127.0.0.1:6379> GRAPH.QUERY authz "MATCH(o1:org {id: 1}) MERGE (p:posusers)-[:member]->(o1)"
(error) Syntax error at offset 28 near 'MERGE'

[swilly22]

Hey @davisford,
Currently RedisGraph does not supports mixing MATCH and MERGE.
This is something we should defiantly support soon.

[ediphy-azorab]

GRAPH.QUERY authz "MERGE (o1:org {id: 1}) MERGE (p:posusers)-[:member]->(o1)" doesn't seem to work either, unfortunately

[swilly22]

@ediphy-azorab correct, we do not support multiple occurrences of clauses for the time being, I suggest combining these two together into a single MERGE clause, or issue multiple queries.

[ediphy-azorab]

@swilly22 I think that would have different behaviour to that query? The double merge should first get or create the org and then create (or get) a relationship between all posusers and that org. My reading of "When using MERGE on full patterns, either the whole pattern matches, or the whole pattern is created" suggests that doing the whole query in one line will create a new org vertex even if one with the right id already exists.

For now I guess I'm going to be doing a lot of MATCH ... CREATE :)

[swilly22]

@ediphy-azorab you're correct! sorry for misleading.
I'll update once we'll support multiple clauses of the same type within a single query.

[wuyanxing]

Now， support mixing MATCH and MERGE?

[swilly22]

@wuyanxing, yet, we're working on replacing our current parser, once that work is done we'll be able to mix MATCH and MERGE, I'll update here once that's done.

[wuyanxing]

Will it be fully supported with cypher syntax? just like neo4j

[swilly22]

@wuyanxing as far as the parsing goes, yes.
I'll have to see what are the implications on our execution plan.

[davisford]

Hi @swilly22 it has been over a year since I posted this issue, and I'm in a spot where we are re-evaluating graph dbs -- this is kind of important for us. Just wonder if you have any update -- understanding this is FOSS and obviously can try to help contribute, but just curious if it is on the roadmap or if there is any plan to support?

[jeffreylovitz]

Hi @davisford ,

Sorry this has been deferred for so long! Since this issue was initially opened, we've entirely replaced our query parser and introduced support for significantly more complex combinations of many clauses.

You're correct, however, that our implementation of MERGE hasn't evolved nearly as much as other clauses. In order to fully support MATCH...MERGE on a relationship - as in the opening post on this issue - we still need to introduce a number of new operations. These include:

• Lock operators for safely reading from and writing to the same data source in one query.
• An Apply operator that conditionally performs tasks when one of its input streams produces a NULL result (this is AntiConditionalApply in Cypher's parlance).
• More finely-grained variants of the actual Merge operation.

Additionally, some changes to execution plan construction need to be made to ensure these operations are composed in the correct tree.

This is all to say, basically, that we're sorry this feature has been delayed for so long! Our team will evaluate where these tasks belong on our roadmap, and I'll report back here with a rough ETA within the next week. That said, given the amount of work I think that a robust MERGE solution will take at least a month to implement.

[hobofan]

@jeffreylovitz Any update on this? :)

I'm currently adding support for RedisGraph to a project of mine which was previously only targeting Neo4J, and ran into this limitation. I think I've managed to work around it by splitting it up into individual statements, but in the future it would be great to be able to use a more expressive syntax and use the same queries across both databases.

[jeffreylovitz]

Sorry, I forgot to update on this issue!

We've moved robust MERGE support up on our roadmap, but the safe ETA is end of 2019. Hopefully we'll manage to implement this sooner, but it can't be guaranteed!

[hobofan]

Thanks, for the update. That's great to hear! Overall very impressed with the recent changes (indexing via RedisSearch and improved Cypher coverage)!

[MichaelHirn]

@jeffreylovitz Are there any news on MATCH ... MERGE support?

We decided that we want to go full in on RedisGraph (instead of Neo4J) and ported everything successfully over to work with RedisGraph ... except for MATCH ... MERGE which is mission-critical for us and we weren't able to find a work-around for it. It's the only missing part and we would love to move forward with RedisGraph, but EOY is too far out for us to wait for it.

Hoping for good news 🤞🤞🤞

[jeffreylovitz]

@MichaelHirn That's great to hear!

We've spent the last few days in planning mode, and have come up with a design that will fully cover all MERGE cases (most critically, MATCH...MERGE, MERGE...MERGE, and MERGE...SET).

Implementation is going to start now; I expect that the changes will be merged and a new RedisGraph version will be rolled out within 3 weeks.

I hope this counts as the good news you were looking for!

[MichaelHirn]

Oh wow, that's fantastic. We can't wait to try it out!

[swilly22]

Support for the MERGE clause (and mixing different clauses with merge) has just been merged :D into the master branch, documentation been updated.

Please report any issue encountered. thanks!