feat(java): add chunk and edge-range primitives - #968
Conversation
|
Hi @SemyonSinchenko — this is a deliberately small, independent Java core slice (419 lines, 6 focused tests) after #960/#962. It provides only the long-safe half-open chunk/range value layer; metadata URI resolution and IO stay out of this PR. I would appreciate your review when convenient. |
|
Updated this PR into the complete ordered-adjacency core vertical (now 848 additions): validated offset chunks, metadata URI resolution, and the canonical LDBC cross-chunk fixture. It remains independent of #961 by keeping Parquet reads out of core. |
|
cc @SemyonSinchenko @SYaoJun — green CI, would appreciate a look when you have time. |
eb6f816 to
a959411
Compare
|
@SemyonSinchenko @SYaoJun could you take a look when you have a moment? This one is rebased on current Note that the I can follow up with a separate PR widening |
|
Update on the CI gap I mentioned above: the fix landed in #966 rather than as a separate PR, since @SYaoJun raised the same point there. The workflow now builds
|
Provide the storage-free arithmetic layer needed by future ordered adjacency readers without coupling it to GraphAr metadata or physical IO. Relates to apache#967. Rejected: resolving metadata layouts or reading offsets in this value-only slice.
Complete the core-only ordered-adjacency contract: validate offset chunks, select exact half-open edge chunk ranges, and delegate URI resolution to immutable GraphAr metadata. Relates to apache#967. Rejected: reading Parquet offsets in graphar-core; io-parquet remains behind the open apache#961 API change.
The workflow's path filters already list maven-projects/core/**, so a change under core triggers the job, but SDK_MODULES left the module out and the reactor never compiled or tested it. A green run therefore proved nothing about core. Add core to the module list so the same job that guards storage and io-api guards it too. The fixture-backed test skips itself when the canonical testing dataset is absent, so the job stays green without the submodule.
a959411 to
a551002
Compare
|
Rebased on I also pushed the answer to the CI question I raised earlier, rather than leaving it open: the workflow already watches Local verification against |
1 participant
Reason for this PR
Implements #967 (and relates to #947/#944): the complete dependency-light Java core contract for resolving an ordered GraphAr adjacency range.
What changes are included in this PR?
graphar-corewith long-safe chunk arithmetic and half-open edge/chunk range value types.EdgeInfoordered-by-source/destination metadata into the exact offset location, edge range, edge-count URI, and selected adjacency chunk URIs.[1008, 1061)at chunk size1024.This PR delegates URI construction to
EdgeInfo; it deliberately does not read Parquet offsets or depend on storage/Parquet. That physical reader belongs after the open #961 IO API change.Are these changes tested?
Yes.
The reactor passes 8 core tests plus the
graphar-infodependency suite.pre-commit run --files ...andgit diff --checkalso pass.Are there any user-facing changes?
Yes. Java consumers can now resolve ordered-adjacency metadata and validated offset ranges to exact GraphAr chunk URIs without introducing physical IO dependencies.
Checklist
make cpplint(if this PR contains C++ changes)pre-commit