crazysummers

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

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

> 分布式下也可以保证唯一性的, 用的开源的 snowflake 算法, 不过图上如果你 vid eid 都是自增生成的话, 查询的时候如何根据 id 查呢? TP 场景下基本都是由点/边 id 出发的遍历 (或者是用于图计算场景么) 其实我有点没太get到为啥查询的时候会由id出发作为查询步骤的开始，即使需要从id出发开始遍历的时候，也应该是已知顶点id的情况，这里其实是会有个前置的查询顶点id的步骤的吧。对于id生成策略的不同理应是不同的业务场景下选用会有差异，但是对于vertex或者edge来说id应该只是一个唯一标志，不同的id策略不应该产生不同的操作限制吧，就像在关系型数据库中无论一个id是数值还是字符串都不应该影响我通过id对某一条记录的修改才对。还是说这里的限制在hugegraph有其他设计考虑呢

> > 而单个更新的接口对于list和set类型的数据又是追加的方式 > > @Ckuangf 这个结论不是预期的，单个更新接口对任何属性都是覆盖的方式。 > 另外，只要知道id的情况下，即使是automatic场景也是支持更新策略的。 可是目前操作起来的话，对于list和set类型的都是进行的追加，文档上面的描述也是追加，我用的是0.11.2版本的，对于automatic场景下 如果可以进行覆盖的话应该要怎么操作呢，因为我看到代码上是有专门做了这个地方的判断，如果是automatic 直接返回了

> > 而单个更新的接口对于list和set类型的数据又是追加的方式 > > @Ckuangf 这个结论不是预期的，单个更新接口对任何属性都是覆盖的方式。 > 另外，只要知道id的情况下，即使是automatic场景也是支持更新策略的。 这个更新这里还发现有个问题，如果我设置了unique索引，然后在更新顶点属性的时候，如果没有变更unique索引的字段值就会报错，好尴尬的设定，难道更新的时候是会先创建一个顶点然后进行替换么

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

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

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

> > 在mysql作为存储后端的时候，使用的语句是replace into，而mysql中是不区分大小写的，所以在插入的时候会出现更新覆盖id和propertis情况，导致插入的顶点丢失 > > 看起来两个解决方案: > > 1. 换一个原本就不区分大小写的 id 字符生成方式 > 2. 让 mysql 导入的时候能区分大小写? > > 似乎优先考虑第二个合力点? 有意愿可以尝试 PR fix 下 这里比较好奇为什么需要在数据库里面存一个Base64的值，如果是为了加密 那使用一个对称加密的方式生成id也可以避免这种情况的。 而且这里似乎会出现的问题具有普遍性，只要是不区分大小写的后端存储 都会有这个风险。最好是能唯一确定入库时的id