keksmd commented on issue #756: URL: https://github.com/apache/incubator-graphar/issues/756#issuecomment-5254632668
I have started the implementation with a small, format-compatible first slice: PR #942 fixes the pure-Java `EdgeInfo` path contract and adds fixture-backed tests against the existing Parquet LDBC data. The accompanying architecture and compatibility documents make these decisions explicit: 1. The logical request is range-oriented, not "read a whole chunk then filter in memory." The graph layer resolves an offset-derived edge range and sends URI, projection, range, predicate, and limit hints to the physical reader. 2. Each backend reports which hints it used. Parquet can push projection/range/predicate work to row groups; a weaker backend may decline a hint without changing result semantics. 3. `graphar-info` stays dependency-light. The initial reader vertical is local storage + Parquet + `ordered_by_source`; it does not make Arrow mandatory and does not introduce a general query AST. 4. The API boundary leaves a place for future planning/AST work without making a query engine a prerequisite for useful traversal reads. The first code gate is deliberately metadata-only: C++-compatible edge count, offset, topology, and property locations, including the required `(adjacency type, vertex chunk, edge chunk)` tuple. It passes `mvn clean verify` in the project devcontainer (124 tests, no failures). This gives the IO layer an unambiguous physical-layout contract before new storage or Parquet modules are added. -- 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]
