Star

【语法】feature需求:临时表概念,$VAR的结果可以通过fetch prop on访问。

要写大程序,这个可能是必须要支持的。
go … | fetch prop on $var yield $var.prop.

看上去是重新select属性?为什么不在go的yield里直接select?

稍微复杂一点,就做不了。完善的变量支持,是大SQL代码必备的。

我觉得是不错的feature,需求得急切么,不急的话可以安排到2.0

已在需求池中,待评审~

现在yield也可以满足这个用法吧,直接yield变量或者pipe输入

变量是table,yield是满足不了的。

go … | yield $var.prop这个和你表达的语义有什么不同么

这个是执行不了的。

create tag temporary tag_name $tmp_tag_var by var_label;

这种语法如何,短时间作用域,和variable行为并列。

这个限制只是现在禁止了,从语义以及实现上面都没有问题,yield来做我觉得会比fetch更合适

$var是一个table,yield返回的是哪一行数据呢

yield返回的也是表

go … | yield $var.prop

用到了两个表,类似于join语义。有很明显的歧义

go … | yield $var.prop on $var.id == $-.id

这样来做完整的join语法么,要区分left join/right join/full join么

你上面写的fetch语句也有两个表,也是要表达join的意思么

是要做join。

如果你的需求就是需要比较通用的join功能,我觉得根据单一职责的原则,可以增加独立的通用join语法,比如
GO ... | JOIN [INNER, LEFT, RIGHT...] $-, $var ON ... WHERE ...
如果可以满足你的需求的话,我就和产品还有开发进一步评估这个方案。

join语法也是我的一个倾向。我拉使用方过来聊

这里的使用逻辑是这样的。因为在复杂的逻辑当中,可能需要每段代码给部分key计算出一个值。最后再使用前面计算好的值关联后一起计算。现在是做不到这一点的。

现在对于tag的使用。其实本质上就是join。通过vid作为key来读取数据。
之所以提出临时tag和临时edge的需求,是考虑最小化改变的因素,还可以基于原始的语法继续开发。

刚刚上面所提到的计算结果变量支持通用join的想法。固然兼容了我所说的临时tag和edge,不过不知道是否在使用上能够完全兼容现有的edge和tag的用法,感觉会导致开发场景修改过大了,另外不知道join是否支持edge的全套用法

yield的用法因为歧义明显,导致语法越来越难读,还是建议不要考虑了。

另外除此之外,还需要添加类似 sql union 的功能。用来行维度上合并不同语句的计算结果。

每个语句返回的table是储存计算数据和结果的基础元素,希望后面的语法都围绕着table来吧

浙ICP备20010487号