imbajin

@lzane emmm, thanks for your effor first, it can run well without plugins. however, the doc and comment with plugins are not clear enough, I try a string of ways...

+1, imbajin (0x00 at imbajin.com)

多谢建议, 这两个优化都是可以的. 另外你通过 `graph.addVertex(params)` 添加也是可以直接传入 ID 的, 可以看下面链接里的 demo 如果现在不想这样自己指定, 你可以使用[主键模式](https://hugegraph.github.io/hugegraph-doc/guides/desgin-concept.html#3-vertexid-%E7%AD%96%E7%95%A5), 自动通过属性生成 ID,

Some other refer: 1. [Apache License 须知 - Linkis](https://linkis.incubator.apache.org/zh-CN/community/development-specification/license)

1. 更新策略目前的确只有批量接口支持, 不过你**传入一个点**也就是单点 + 更新策略的更新了, 没有影响的 2. 是否非空都可以通过增加 `OVERRIDE` 参数选择 **覆盖** 还是 **保留** 原有非空的值, 空值直接覆盖也并不影响. 其他的描述没太理解意思, 你可以试试单个点的批量更新, 然后有其他问题再更新反馈 (另外标题简短描述问题即可, 希望能保持原有模板风格 --> `[Question] xxx `, 关于 issue 模板的建议也欢迎反馈~ 😄 )

这样, 那就是说你也不想覆盖其他属性, 只是单纯希望更新的时候覆盖 `list / set` 属性, 又是自增策略的 ID是吧. 那目前默认的确没太好的办法, 不过是否能更新某个属性也跟后端有关的, 你可以 `gremlin` 的 `property()` 尝试单个更新覆盖试试. PS: 因为自增 ID 我理解一般是测试的时候用的, 它本身也有不少局限性, 以至于有些接口就没特殊考虑它, 不然会增加不少复杂性, 正常生产环境应该不会用自增 ID 的方式吧.

分布式下也可以保证唯一性的, 用的开源的 snowflake 算法, 不过图上如果你 vid eid 都是自增生成的话, 查询的时候如何根据 id 查呢? TP 场景下基本都是由点/边 id 出发的遍历 (或者是用于图计算场景么)

> 可是目前操作起来的话，对于list和set类型的都是进行的追加，文档上面的描述也是追加，我用的是0.11.2版本的，对于automatic场景下 如果可以进行覆盖的话应该要怎么操作呢，因为我看到代码上是有专门做了这个地方的判断，如果是automatic 直接返回了 0. 关于你说的遍历方式, 可否给几个你现在使用 gremlin 的语句例子呢? 大部分查询一般是 `g.V(vid).xxx()` 类似的, 所以的确是已知点 id 的情况比较多, 如果点 id 完全不清楚, 那在没有索引的情况, 如何开始遍历呢? 图和 mysql 模型差别很大, 所以他的 vid/eid 都比传统关系数据库重得多, 而且它的 eid 直接由 vid...

嗯呢, `hasLabel()` 实际就走了一层索引了, 不然 label 查询也会扫表, 因为 `vid / eid` 未知, 所以基本也就这类办法去扫表. 而且不知道你现在如何写边的, 因为你 `vid` 必须查询出来才知道, 所以如果要新增边, 应该也比较麻烦. 普通写入就是新增一个顶点的 api (指定 vid 和原来一致就行), `PUT` 在 REST-ful 语义里就是更新, 索引那个感谢反馈

- unique 索引是单独的问题, 就分开看就行. - `automatic` 策略和关系型 DB 的自增差别很大, 最典型的问题就是边 id 是由点 id 构成的, 比如 loader 你导入边, 但是因为 automatic 你都不知道 vid 是什么, 你必须先去读点才能知道 vid, 那自然跟其他自指定 id 的情况有很大差别 - 单个更新和批量不是一个时间加入的, 主要是批量更新带了多种策略,...