dpol1 commented on issue #3145: URL: https://github.com/apache/hugegraph/issues/3145#issuecomment-5231627813
Compatibility inventory, first pass. Analyzed at master `c10779dc6` (the base of PR #3146). Counting rule: production sources only — test code, generated sources, and the bundled dist copy are excluded. File:line evidence exists for every cell, happy to expand any row. | Candidate (module) | Wired production surface | Persisted or wire boundary | Existing oracle | Java fallback / PoC risk | |---|---|---|---|---| | `LongEncoding` (commons) | `encodeNumber`, `encodeSignedB64`, `decodeSignedB64`, `validB64Char` in 7 files; `decodeSortable`/`decodeNumber` have no production callers today | encoded strings embedded in vertex ids (primary-key strategy), edge sort keys, index ids and values, stored-string ids; the same contract reaches the store side via the struct copies of `IdGenerator`/`ConditionQuery`/`PropertyKey` | `LongEncodingTest`, golden corpus (PR #3146) | fallback cheap: final class, static pure functions, no state | | `NumericUtil` (commons) | sortable conversions and byte helpers in 20 files | range-index row keys, `LongId` bytes, HBase counter cells; algorithm derived from Lucene `NumericUtils`, effectively frozen | `NumericUtilTest`; the corpus pins it only transitively via `encodeNumber` | fallback cheap: static, stateless; the byte-array surface has no golden corpus yet | | `BytesBuffer` (server/core) | serializer stack, 26 files | the binary row format itself for every backend, raft log entries, client-visible page tokens; non-primitive property values embed Kryo bytes | `BytesBufferTest`, `BinarySerializer` round-trip tests | high: byte layout is the on-disk format, process-wide config state, Kryo coupling | | `BytesBuffer` (hugegraph-struct, consumed by hstore modules) | store read/query paths, 16 files | gRPC `ByteString` id fields (wire) and RocksDB keys and values on the store side (disk) | none — no test imports this copy | high, and currently uncharacterized | | `IntSet`/`IntMap` (server/core) | traversal records only, 4 files | none: per-request, in-heap | `IntMapTest`, `IntSetTest`, JMH benchmark | state cheap, but the concurrency contract is real (`concurrent=true` in K-neighbor/K-out) and the implementation sits on `sun.misc.Unsafe`, which is on the JEP 471 removal path | Findings that actually move the selection: 1. `LongEncoding`'s wired surface is narrower than its API: production never calls `decodeSortable`/`decodeNumber`. The corpus still locks them (they are public contract), but a PoC can be judged on the four wired operations. 2. `NumericUtil`'s byte-array surface (`numberToSortableBytes` and friends, used in range-index keys) is the natural next corpus once the shape of #3146 settles. 3. Facts about the two `BytesBuffer` copies, recorded separately: the struct copy declares `ID_LEN_MAX = 32768` but its `writeId` enforces a literal 16384 and the declared constant is referenced only in a comment; the core copy declares `ID_LEN_MAX = 16384`; `BLOB_LEN` is 5 in core and 4 in struct; git history shows the struct file was extracted from the core one in 2025-09 while the core copy kept evolving (latest 2026-06, #3049); no test currently locks the struct copy. Whether the two copies must interoperate on the same byte format is one of the open points below. Until that contract is stated, the safe deliverable is a characterization fixture per copy, not a cross-copy equality test. 4. `IntSet`/`IntMap`: only 4 production call sites and transient state, so porting value looks low; the direct `sun.misc.Unsafe` usage matters for JDK upgrades independently of any Rust work. Side note: `IntMapByDynamicHash` has tests and a JMH benchmark but no production wiring. Open points I could not settle from the tree — input welcome, and @dosu feel free to take a first pass: - whether hugegraph-server's core `BytesBuffer` and the hstore struct copy ever need to read each other's bytes, or the two formats live behind separate boundaries; - whether the store ingest path writes struct-`BytesBuffer`-encoded bytes, or only re-encodes on read and query; - whether external tools (loader, hubble, tools) parse or generate the binary row format; - whether stored Kryo-encoded property values are guaranteed readable across a Kryo upgrade, and whether page tokens are expected to survive a server upgrade. I'll fold the answers into the matrix as they come. -- 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]
