Star

当顶点不存在时计算结果的一些疑问

操作步骤如下(tag和edge已经创建好了)

--插入边
INSERT EDGE someEdge(v) VALUES 100 -> 101:('test1');
INSERT EDGE someEdge(v) VALUES 100 -> 102:('test2');
INSERT EDGE someEdge(v) VALUES 100 -> 103:('test3');

--插入点
INSERT VERTEX someTag(v) VALUES 103:('test3');

--执行查询操作
go from 100 over someEdge yield '100' as k,$$. someTag.v as v | group by $-.k yield count($-.v)

--结果
3

疑问
1.应该返回3嘛?
2.我想返回1,应该咋写或咋办?…

感谢

$-.k 都是100,一共三条记录,count当然是3

GO FROM 100 OVER someEdge YIELD someEdge._src as k, $$.someTag.v as v

1赞

不是…大佬…这不是关键…
关键是我没建那么多点~ 我就建了个103的点

按底层存储结构来看
第一步 通过100发散出去,找到了三个顶点id
第二步 通过顶点id和tagid去找到顶点

我的意思是 在第二步的时候 如果按顶点id+tagid去找顶点的话 应该只能找到1个呀~

你这个查询只有一步

主要你插入两个点是不存在的,但是你又去拿属性,就会返回默认值,可以加过滤

go from 100 over someEdge WHERE $$.someTag.v != '' yield '100' as k,$$.someTag.v as v |yield count(*)
2赞

谢谢您,按您的建议我已经可以得到我想要的结果了


参考您之前回复,终点的属性过滤是没有下推的

假设存在一种情况(不是真实的,我举个极端一点儿的例子)
一个顶点连着1w条边,但是其中只有100个顶点是存在的
如果没有计算下推,会不会非常浪费资源呢?这块儿是否需要进行优化?

另外,
我发现您说的返回 默认值, 这个默认值应该不是创建tag时候的默认值吧

我发现您说的返回 默认值, 这个默认值应该不是创建tag时候的默认值吧

不是创建schema的默认值,这里的默认值相当于NULL,只是暂时不支持 NULL这个类型,所以返回了每种数据类型的默认值,比如字符串就是空字符串,int就是0……

参考您之前回复,终点的属性过滤是没有下推的
假设存在一种情况(不是真实的,我举个极端一点儿的例子)
一个顶点连着1w条边,但是其中只有100个顶点是存在的
如果没有计算下推,会不会非常浪费资源呢?这块儿是否需要进行优化?

假如用户插入了大量的边,但是点是不存在的情况,这个现在是没有优化的,这块是由用户自己根据业务场景去控制

1赞

好的,我都明白了~ 非常感谢~~

假如用户插入了大量的边,但是点是不存在的情况,这个现在是没有优化的,这块是由用户自己根据业务场景去控制

我这里没说清楚,这里的默认值是在graphd这里填充的。

1赞

嗯嗯 ~ 明白了 ~ 但是就是感觉好累… 辛辛苦苦一顿填充,填充完了我又咔咔给where过滤掉了… 感觉不存在的顶点就没必要拿出来了,更何况还自动填充了默认值,填了默认值还和创建时候的默认值不一致,容易让人混淆

我提了个issue 希望能优化一下这块儿,不过我没有考虑太多别的方面是否有影响,如果不合理还劳烦您close一下~ 谢谢~

好的,非常感谢你的反馈,我们这块会考虑更好的用户体验的。
后续可以这样,用户只拿目标点的属性和id的时候,这块是没必要填充默认值返回的;但是用户又拿边的属性和点的属性,这个是一定要填充的,在2.0是支持 null,将填充 null。

嗯嗯 您说的这两种情况的处理方式非常完美~

浙ICP备20010487号