v6: quantizer settings use snake_case names the server never reads

从 src/main/java/io/weaviate/client6/v1/api/collections/quantizers/ 开始，并对照 issue 中列出的 server sources 检查 RQ、BQ、SQ 和 PQ records。验证 camelCase keys 的 serialization 和 deserialization，以及 PQ 的嵌套 encoder 结构；完成的标准是所有受影响的 settings 都使用 server 的确切名称进行 round-trip。

Summary

The quantizer records use snake_case JSON names the server never reads. Weaviate parses these settings out of the config map by exact key, so everything except enabled, bits, segments, centroids and cache is silently dropped on write and null on read — on every index type, not just one. A user who sets a rescore limit never set one.

The mismatch

The server reads them like this — a plain map lookup, no case folding, no snake_case fallback:

// entities/vectorindex/hnsw/rq_config.go
if err := common.OptionalIntFromMap(rqConfigMap, "rescoreLimit", func(v int) {

and returns them under the same names:

type RQConfig struct {
    Enabled      bool  `json:"enabled"`
    Bits         int16 `json:"bits"`
    RescoreLimit int   `json:"rescoreLimit"`
}

So the break is symmetric: what the client sends is ignored, and what the server returns does not bind to the client's fields.

Affected fields

src/main/java/io/weaviate/client6/v1/api/collections/quantizers/:

• RQ.rescoreLimit, BQ.rescoreLimit, SQ.rescoreLimit
• SQ.trainingLimit, PQ.trainingLimit
• PQ.bitCompression
• PQ.encoderType, PQ.encoderDistribution — these are flat components in Java but a nested encoder object on the server, so they need a shape change rather than just a rename

enabled, bits, segments, centroids and cache already match and are unaffected.

Suggested fix

Rename the annotations to the camelCase keys, and give PQ's encoder its nested shape. No alternate values are needed: the snake_case spellings were never valid on the wire, so no stored config uses them.

Version

• java-client 6.3.1 (present since the quantizer records were introduced)
• Weaviate 1.39.0

Found while investigating #606, which is unfixable in practice without this: locating a nested rq still yields a null rescoreLimit.