function on field names does not work when the nGQL starts with 'LOOKUP'

[xiaominyan88]

Cluster Config
metad: 3
graphd: 6
storaged: 6

Space Config
VID: FIXED_STRING(30)
Replica factor: 1
Partition Num: 30

Problem
When the nGQL starts with 'LOOKUP' and threre are some functions on field names after WHERE condition, such as:

LOOKUP ON comment WHERE timestamp(head(split(comment.creationDate,"."))) < 1304208000000 YIELD id(vertex) AS vid

the error occurs:

-1009:SemanticError: Expression (timestamp(head(split(comment.creationDate,".")))<1304208000000) not supported yet

However, when I modify the nGQL with 'GO', such as:

GO FROM "15393162822759" OVER comment_hasCreator_person REVERSELY WHERE timestamp(head(split(properties($$).creationDate,"."))) < 1304208000000 YIELD id($$) AS vid

the nGQL works well, it seems that there are differences on function process between 'GO' and 'LOOKUP'

[QingZ11]

what's your nebulagraph core version?

[wey-gu]

For the lookup query, it's a typical tabular query(or, not a graphy one), that is, when we are query data with LOOKUP, it's a duplicated data on given tag/edgetype stored in a tabular way(like RDBMS), and NebulaGraph is not designed for such purposes.

Thus, the expression like timestamp(head(split(comment.creationDate,"."))) < 1304208000000 in LOOKUP means to actually fetch all "rows" of comment TAG's creationDate column from storaged(s) to graphd then evaluate the outer layers(function split, head, timestamp). Whereas for some other expression like comment.creationDate < "2021-01-02", it could be translated to a underlying prefix scan, thus the filter could be applied(push down) to storaged when scaning the index data.

While in GO case, the filter expression can be done as it's just filtering on top of one graph traversal fetched data, thus in such volume of data(one hop graph traversal v.s. full scan of tag:comment), it's allowed and acceptable.

Actually, the GO case with comment.creationDate < "2021-01-02" might be more efficency(not yet verified but could be) as the filter could be pushed down during the traversal, too.

[xtcyclist]

This is not a bug, as explained by @wey-gu. Close this issue for now.

If you want more functions from LOOKUP, please issue some feature requests. Thanks.