MERGE incorrectly creates multiple vertices

[mingfang]

SELECT * FROM cypher('playground', $$
unwind ["foo", "foo"] as each
merge (v:TEST {name: each})
return v
$$) AS (v agtype)

returns

[
  {
    "v": {
      "id": 3659174697238531,
      "label": "TEST",
      "properties": {
        "name": "foo"
      }
    }
  },
  {
    "v": {
      "id": 3659174697238532,
      "label": "TEST",
      "properties": {
        "name": "foo"
      }
    }
  }
]

creates two vertices when it should only create one. (confirmed with neo4j)

[mingfang]

maybe same as #1446

[jrgemignani]

@mingfang This is expected behavior. The key name is a property of a vertex, in this case. Vertices and edges are allowed to have the same properties.

[mingfang]

@jrgemignani please note in my test case the problem is that MERGE created two vertices with the same name, and not one vertex and one edge.

[jrgemignani]

@mingfang Yes. I was just stating that this is also the case for edges. Vertices can have duplicate properties and edges can have duplicate properties. Properties are not unique.

[mingfang]

I'm sorry but I don't think that's correct.
I've tested this in neo4j and it only results in one vertex created, not two like in AGE.
Here is the neo4j doc that speaks directly to this
https://neo4j.com/docs/cypher-manual/current/clauses/merge/#merge-merge-single-node-specifying-both-label-and-property
Merging a single node with both label and property matching an existing node will not create a new node:

[jrgemignani]

@mingfang I stand corrected. It seems odd, though, that properties would be unique in this sense. We will likely need to adjust the contains versus equals operator for this case.

[mingfang]

Also this is only a problem when multiple MERGE are called in the same query.
e.g. this works as expected, only one vertex is created after both queries.

SELECT * FROM cypher('playground', $$
unwind ["foo"] as each
merge (v:TEST {name: each})
return v
$$) AS (v agtype)

SELECT * FROM cypher('playground', $$
unwind ["foo"] as each
merge (v:TEST {name: each})
return v
$$) AS (v agtype)

I'm guessing that multiple MERGE in the same query somehow is not seeing each statement's "state" since the transaction is not committed yet. Totally a wild guess.

[jrgemignani]

Yeah, the more that I look at it, the more it appears to fall there. Transaction bugs, though, can be a pain to fix. Especially, for merge.

[jrgemignani]

@mingfang This is an interesting one.

[jrgemignani]

@mingfang The particular cause for this issue is hard to easily describe, especially without getting very technical. Suffice to say, that MERGE (within the execution of a MERGE command instance) can't (or doesn't) see what it has just created.

In most cases, this isn't an issue because MERGE only CREATEs what isn't already there. However, when it is driven externally, it is possible for it to have duplicates for duplicated data. I'm not sure if this is the only case where this is possible, though.

I am looking into how to allow MERGE to know prior to inserting a duplicate and if this can resolve the issue. This may take some time, though, to implement.