INSERT或UPDATE如何与|管道一起使用以及如何批量给符合条件的点增加标签或修改属性

[zhe1234zou]

需求：
当前项目由于数据量增长超过预期，考虑将neo4j迁移到nebula；测试发现原查询算法中使用label用于加速查询，但在转义查询算法过程中发现INSERT无法与|管道一起使用，因此需要过于复杂的代码逻辑才可以实现标记过程，我查阅NebulaGraph Database 手册发现如下描述；

测试发现INSERT无法与|管道并用，只能打断查询过程单独增加标签实现，由于大部分算法都需要多层深度查询，就导致代码处理起来异常繁琐；

另我查阅到如下描述，但我未找到如何使用管道复合查询实现读写同时操作；
原CQL查询语句：

问题：
第一、nGQL原生语法是否有比较优雅的解决方案不需要打断查询过程？
第二、如果没有类似的方法，未来是否考虑增加类似方法？
第三、将来是否支持 OpenCypher create、MERGE等操作，使类似的算法可以通过 兼容OpenCypher实现？

[MuYi]

@zhe1234zou

第一、nGQL原生语法是否有比较优雅的解决方案不需要打断查询过程？

第一、nGQL原生语法是否有比较优雅的解决方案不需要打断查询过程？
MuYi：暂无，因为不支持事务，所以不好做match insert/update。

第二、如果没有类似的方法，未来是否考虑增加类似方法？
MuYi：考虑；已规划中。

第三、将来是否支持 OpenCypher create、MERGE等操作，使类似的算法可以通过 兼容OpenCypher实现？
MuYi：未来会支持ISO-GQL，里面目前没有定义MERGE，不过有match insert。

[zhe1234zou]

如果不考虑事务，增加类似的方法是否可以增加类似于临时标签或者临时状态的方法只对当前查询过程生效

[zhe1234zou]

测试发现删除标签DELETE 支持管道方法，如下语句可行：
lookup on TAG_LINE_NODE_1 yield id(vertex) as id |
DELETE TAG TAG_LINE_NODE_1 FROM $-.id
不支持事务不好做match insert/update，但同样的写操作的DELETE 却支持，让人比较困惑产品逻辑；

[MuYi]

当时我估计是因为考虑到delete操作不一致的话风险较小。再删一遍就行。
但insert和update如果操作失误的话不太容易回滚。

[zhe1234zou]

既然不支持事务就不该为用户考虑回滚问题怎么处理，如上图所示我的查询语句在查询过程中会产生非常多的标签无法在当前过程中删除，我需要使用union语句或者查询完成后单独清理相关标签；
我个人认为既然不支持事务就该将决定权交予用户，让用户自行处理引发的问题；而不是既没有解决用户使用风险又限制用户使用灵活度

[Salieri]

我个人是认同您的观点的，事实上我们现在正在支持的ISO-GQL也允许了这种操作。

[zhe1234zou]

我略微了解了一下ISO-GQL，好像还未成为正式标准FDIS 投票尚未开始，按计划标准公布也已经是明年中期了，到时相关支持是否稳定以及执行效率可能又会成为新的问题；
为什么不考虑在原生语句中实现？并且我们在使用过程中还发现了其他问题，如match查询效率高于原生go，感觉官方对原生nGQL重视程度一般。

[steam]

因为一开始没有图查询标准，NebulaGraph 自研了一套 nGQL。后来 GQL 出来了，NebulaGraph 从 2.x 开始支持 openCypher（也是一个 GQL 参考查询语言）到 3.x 做了更多的 openCypher 以及相关的子句的性能优化，你可以理解为这几个版本都为了向图查询事实标准对齐，所以 nGQL 慢慢就不是优化重心了。

cc @MuYi 你有啥补充的么？