SebastianGruza opened a new pull request, #3375: URL: https://github.com/apache/hugegraph/pull/3375
## Purpose of the PR Closes #3225. A graph on HStore (or RocksDB) whose config did not set `serializer` opened with the option's default `text`: writes were stored through `TextSerializer`, and every read failed with `BufferUnderflowException` because the backend parses stored keys as binary. Nothing in the log pointed at the config line. Per the discussion on the issue, the serializer is no longer a user-facing choice: the backend picks it. ## Main Changes - `BackendStoreProvider.serializerName()` / `acceptsOtherSerializer()`: a backend declares the serializer it reads and writes. hstore and rocksdb (and the raft wrapper, by delegation) are `binary` only; `memory` declares `text` (its tables hold `TextBackendEntry` rows); hbase declares its own `hbase` serializer. - `StandardHugeGraph.serializer()` takes the backend's serializer when the config does not name one. An explicit `serializer` on a binary-only backend that does not match fails at open with `The hstore backend requires serializer=binary, but got 'text' (graph 'x'); remove the serializer line from the graph config` instead of surfacing as a buffer exception on the first read; a legal override on another backend logs a warning that the option is legacy. - `CoreOptions.SERIALIZER` keeps working as a legacy override but has no default any more; its Javadoc carries the TODO to remove the option and the selection logic in `SerializerFactory` / `StandardHugeGraph.serializer()` once no shipped config or test sets it. - The `serializer=binary` line is removed from the shipped `conf/graphs/hugegraph.properties`, `hstore.properties.template`, the example config, the three raft CI configs, `start-server.sh`, the HStore docs, and from the auto-filled configs of `GraphsAPI` and the system graph. Compatibility: a config that still sets `serializer=binary` on hstore/rocksdb keeps working unchanged; `serializer=text` on those backends, which never read back its own rows, now fails fast. The `memory` backend keeps `text`, the `hbase` backend its serializer, so the CI profiles do not change. ## Verifying these changes - [x] Unit: `SerializerFactoryTest.testSerializerNameComesFromTheBackend` (backend default, matching override, rejected override with the message and the graph name, `memory` on text, a lenient backend accepting an override); `HugeFactoryTest`, `GraphManagerConfigTest` (74), `RequestCacheLifetimeTest`, `MultiGraphsTest`, `TextSerializerTest`, `BinarySerializerTest` unchanged and green. - [x] A server built from this branch with the shipped config (no `serializer` line) on rocksdb: `VertexApiTest`, `EdgeApiTest`, `SchemaApiTest` pass through REST; the same dist with `serializer=text` added refuses to load the graph with the message above (and no `BufferUnderflowException`). - [x] hstore on a PD + 3 Store lab, server built from this branch: with the shipped `hstore.properties.template` (no `serializer` line) the graph opens, a property key, a vertex label and a vertex are created, and the vertex reads back by id and through the list API (the exact scenario of the issue, no `BufferUnderflowException`); the same dist with `serializer=text` added refuses to load the graph with `The hstore backend requires serializer=binary, but got 'text' (graph 'DEFAULT-ser3225'); remove the serializer line from the graph config`. ## Does this PR potentially affect the following parts? - [x] Introduce new configurations: none (one option loses its default and becomes legacy) - [x] Configuration templates change: `serializer=binary` removed from the shipped graph configs (documented above) 🤖 Generated with [Claude Code](https://claude.com/claude-code) -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
