Star

边的rank信息是否可以修改为string类型

  • 需求原因 / 使用场景
    需要使用图数据库描述两个节点间的大量交互过程
  • 需求描述
    需要在两个节点间建立大量相同类型但是属性不同的边,测试过nebula的这种场景,如果不使用rank的话新插入的边应该是会覆盖掉先前的边的,因此就在考虑加入rank,但是nebula的rank仅支持整数类型,这就不得不让我们加入hash函数来将字符串整数化,带来了一些使用上的不便,不知道nebula后期会不会考虑加入对于相同两节点间边虽然类型不同但是边的属性不同的情况进行自动的rank管理能力?或者支持rank的字符串格式?
    另外一个类似的需求就是对于2.0中的string类型的id由于限定长度是否可以支持下自动的哈希或者md5的转换,用户输入的是不定长的字符串但是系统内部存储的节点id是md5后的固定长度字符串,这样就可以屏蔽掉用户真实字符串长度要被限定的问题了
  • 该需求的参考资料(若无,可不填写)

不可以,目前rank只有int类型

那你看这个issue可行吗:

1赞

感谢你的试用,我们PM小姐姐将对你的需求统一评估。
@jude-zhu

那 用户在调用的时候,自己call hash() ,似乎也一样?

是的,现在也可以,但是studio的2.0版本的探索已经取消了hash的入口选项。另外,这个如果配置成系统的默认功能,那用户在操作时自行决定是否关闭自动哈希能力不是更好吗?而且还可以做到更方便的使用。

感觉 md5 如果做在 storage 层会有性能问题,因为每一个 vid 都要做一遍 md5 值,而且还有个问题怎么区别当前的 vid 是已经做过 md5 计算的还是没做过的,比如用户查询走2步,第一步是用户输入的 vid,后面一步是 storage 存储的 vid,怎么判别哪个需要计算呢?

感觉和系统自带的hash函数差不多吧,不知道感觉对不对 :joy:

hash 函数是不一样的,这个是用户手动指定,本质上是一个 FunctionCall,Storage 层拿到的始终是 hash 后的值,不感知 hash 的存在,现在你不想在 nGQL 层面手动输入,那就要底层存储感知是不是已经做过 md5 后的值。这两者还是有不同。

附议。 这个md5 call是应用层的。

浙ICP备20010487号