Is it possible to distinguish similarly named properties belonging to same vertex in a MATCH query in Nebula Graph?

Question

I'm playing with Nebula Graph 2.0.0.

I create two tags, both contain a property called name:

create tag t1(name string)
create tag t2(name string)

Now I insert a vertex giving it t1.name property:

> insert vertex t1(name) values '1': ('first-name');
Execution succeeded (time spent 2730/95913 us)

I can see that it can be found by ID:

> match (x:t1) where id(x) == '1' return x
+-------------------------------+
| x                             |
+-------------------------------+
| ("1" :t1{name: "first-name"}) |
+-------------------------------+
Got 1 rows (time spent 2713/95756 us)

I can also find it by ID and t1.name:

> match (x:t1) where id(x) == '1' and x.name == 'first-name' return x
+-------------------------------+
| x                             |
+-------------------------------+
| ("1" :t1{name: "first-name"}) |
+-------------------------------+
Got 1 rows (time spent 2827/100963 us)

Now I assign t2.name to the same vertex:

insert vertex t2(name) values '1': ('second-name');

It is added ok:

> match (x:t1) where id(x) == '1' return x

+--------------------------------------------------------+
| x                                                      |
+--------------------------------------------------------+
| ("1" :t1{name: "first-name"} :t2{name: "second-name"}) |
+--------------------------------------------------------+
Got 1 rows (time spent 3579/96685 us)

And I can still search by ID and t1.name:

> match (x:t1) where id(x) == '1' and x.name == 'first-name' return x
+--------------------------------------------------------+
| x                                                      |
+--------------------------------------------------------+
| ("1" :t1{name: "first-name"} :t2{name: "second-name"}) |
+--------------------------------------------------------+
Got 1 rows (time spent 2534/96306 us)

But when I search by ID and t2.name, nothing gets found:

> match (x:t1) where id(x) == '1' and x.name == 'second-name' return x
Empty set (time spent 3383/96788 us)

So, probably, under the hood, the system thinks I want to search by t1.name, so it finds nothing.

In a different session, with tags named differently, I got a different behavior: after adding a second name property, I lost ability to search by first name, but it was possible to search using the second name.

Here are my questions:

1. Is it even legal to have on same vertex properties with same name (but coming from different tags)?
2. If so, how can I ask the query executor to use the specific property (for instance, t1.name or t2.name and not the one that the system chooses automatically)?

Answer 1

Good catch! Tag is not that native to OpenCypher actually, we nebula is working work support more and more OpenCypher features, and to make it better. 1 Under the hood, the vertex property matching is based on the nebula index, which is now based on one tag only for now(it's actually left RocksDB key match). 2 when the condition/index matching was done, in MATCH call, you can return all tags' props belongs to it.

Is it even legal to have on same vertex properties with same name (but coming from different tags)?

It's legal. But maybe in most cases, the name could be the same in both tags?

Actually, here the WHERE CLAUSE: where id(x) == '1' is like a Primary Key, thus one Vertex is specified already. In your use case, is it still needed for further AND condition, please?

If so, how can I ask the query executor to use the specific property (for instance, t1.name or t2.name and not the one that the system chooses automatically)?

For the reason: 1(prop index can support only one tag/edge type) now, we can only filter within one tag, thus it's either t1.name or t2.name, like t1.name == "foo" and t1.age > 18.

The interesting case you found() is because the prop-index-selection(which is rule based selection, for now, there will be more improvements on this) cannot be done due to id(v) == 123 is not prop-index based and both tags' prop-indexes are of "name".

To avoid this, maybe we shouldn't allow the same prop-name across tags that belong to the same vertex with different values, this could be improved from docs or code.