does nebula support outputting the attributes of a specified tag of a vertex?

[may11544]

nebula version:2022.11.15-nightly

A simple example.I want to get all attributes with the tag name of default on vertex with the vid of 10.2.29.88.
Think according to inertia,I will write ngql statements like this

MATCH (v) WHERE id(v) IN ["10.2.29.88"] RETURN properties(v.default)
or
MATCH (v) WHERE id(v) IN ["10.2.29.88"] RETURN properties(v:default)

But the above two statements will report errors

It is said that nebula already supports the writing method of .

What I want to know is that there is something wrong with my writing method or the current version does not support

[xtcyclist]

Bug:

(root@nebula) [nba]> match (v) where id(v) == "Tim Duncan" return v.player
+----------------------+
| v.player             |
+----------------------+
| {}                   |
+----------------------+
Got 1 rows (time spent 2982/3311 us)

Expected:

(root@nebula) [nba]> match (v) where id(v) == "Tim Duncan" return v.player
+-------------------------------+
| v.player                      |
+-------------------------------+
| {age: 42, name: "Tim Duncan"} |
+-------------------------------+
Got 1 rows (time spent 2863/3245 us)

[Milittle]

nebula version:2022.11.15-nightly

A simple example.I want to get all attributes with the tag name of default on vertex with the vid of 10.2.29.88. Think according to inertia,I will write ngql statements like this

MATCH (v) WHERE id(v) IN ["10.2.29.88"] RETURN properties(v.default) or MATCH (v) WHERE id(v) IN ["10.2.29.88"] RETURN properties(v:default)

But the above two statements will report errors

It is said that nebula already supports the writing method of .

What I want to know is that there is something wrong with my writing method or the current version does not support

wrokaround: you can use the follow manner:

MATCH (v:default) WHERE id(v) IN ["10.2.29.88"] RETURN v;

[xtcyclist]

It's a bug from the optimizer. The requested properties have been pruned out, as the optimizer thought they were not needed.

[wey-gu]

Yes, this should be implemented(to express all properties on the given tag in some way) when the tag is required as a nebulagraph cypher dialect, or the workaround will introduce extra scan and fetch efforts like properties(v), v

Looking forward to the expression of RETURN v.player or RETURN properties(v.player)

[xtcyclist]

Yes, this should be implemented(to express all properties on the given tag in some way) when the tag is required as a nebulagraph cypher dialect, or the workaround will introduce extra scan and fetch efforts like properties(v), v

Looking forward to the expression of RETURN v.player or RETURN properties(v.player)

It's already implemented. The executor supports it. It's just that the optimizer didn't expect v.tag and pruned all properties of it.

[wey-gu]

Yes, this should be implemented(to express all properties on the given tag in some way) when the tag is required as a nebulagraph cypher dialect, or the workaround will introduce extra scan and fetch efforts like properties(v), v
Looking forward to the expression of RETURN v.player or RETURN properties(v.player)

It's already implemented. The executor supports it. It's just that the optimizer didn't expect v.tag and pruned all properties of it.

You are amazing ❤.