The vectorset API, for mutate, is unusually granular - one element per command; it feels like a number of the mutate APIs would benefit from allowing variadic usage (on a single vectorset); not least, from the outsider perspective (i.e. I have absolutely no relevant domain knowledge) it feels like this should allow potential optimizations in terms of adjacency maintenance.

Suggestions:

  • VADD (probably the highest usage mutate API) - I believe that most of the args don't make sense other than the first element - and even if they do: perhaps we can assume that a single VADD should take identical values (if not: eat the multiple commands); that leaves, potentially: VADD key [REDUCE dim] (FP32 | VALUES num) vector element [CAS] [NOQUANT | Q8 | BIN] [EF build-exploration-factor] [SETATTR attributes] [M numlinks] [(FP32 | VALUES num) vector element [SETATTR attributes]...], i.e. the only variadic parts are the vector (where FP32 or VALUES implicitly says "new element incoming", the element, and optionally the attributes - all the other values are assumed to match the 1st element; a minimal bulk load (without attributes) would then be (existing VADD command for blob1/member1) FP32 blob2 member2 FP32 blob3 member3 FP32 blob4 member4 ... - but SETATTR attrN could optionally be used after each, before the next FP32/VALUES
  • VREM - potentially VREM key element [element ... ]
  • VSETATTR - potentially VSETATTR key element "{ JSON obj }" [element "{ JSON obj }"...] - returns the number of successfully added elements (hopefully N)

I'm coming at this mostly from a "what do I expect the API to look like?" perspective, thinking of things like SADD / ZADD, SREM / ZREM, and HSET respectively, and also (in the case of ZADD) thinking of bulk load throughput.

Thoughts?

Comment From: kevin-montrose

I believe additionally variadic options for: - VGETATTR - VGETATTR key element [element ...] - VISMEMBER - VISMEMBER key element [element ...]

Also fit nicely.

It's a pity, but I don't think there's a nice way to extend VEMB and VLINKS. Those are relatively niche though.

Comment From: mgravell

Indeed, because of the [RAW] I couldn't think of an unambiguous way of implementing such. But if we did, I'd wager that we'd want to optimize for FP32, so maybe there's potentially a "VEMBFP32 key member [member ..]]" that returns either a string (for one member) or an array of strings... Or something.

Message ID: @.***>