Core: Add Java reference implementation for relation load endpoints#15831
Core: Add Java reference implementation for relation load endpoints#15831stevenzwu wants to merge 4 commits intoapache:mainfrom
Conversation
Add DTOs, parsers, handlers, and client methods for the universal
relation load endpoints (GET /v1/{prefix}/namespaces/{namespace}/relations/{relation}
and POST /v1/{prefix}/relations/batch-load) defined in the REST spec.
New types:
- CatalogObjectType enum (TABLE, VIEW)
- LoadRelationResponse with discriminated table/view branches
- BatchLoadRelationsRequest/Response with per-item status codes
- BatchLoadRelationsForbiddenResponse (allOf ErrorModel pattern)
Modified:
- ResourcePaths, Endpoint: new route constants and path builders
- RESTSerializers: registered serializers for new types
- ErrorHandlers: added relationErrorHandler
- CatalogHandlers: loadRelation and batchLoadRelations server handlers
- RESTSessionCatalog: loadRelation and batchLoadRelations client methods
- RESTCatalogAdapter, Route: test adapter handler cases
Made-with: Cursor
Model: claude-4.6-opus-high-thinking
Made-with: Cursor
stevenzwu
force-pushed
the
rest-relation-endpoints
branch
from
0dc0209 to
1dc289a
Compare
… implementation Move CatalogObjectType enum from core/rest to api/catalog for broader API visibility. Add Relation class with forTable/forView factory methods and SupportsRelations interface defining loadRelation and loadRelations APIs. RESTCatalog implements SupportsRelations, delegating to RESTSessionCatalog which handles ETag caching for tables and constructs full Table/View objects from REST responses. Made-with: Cursor Model: claude-4.6-opus-high-thinking
Add TableIdentifier field to Relation so consumers can identify which object each relation corresponds to. Add notFound(TableIdentifier) factory method for representing non-existent objects where only the identifier is known. Made-with: Cursor Model: claude-4.6-opus-high-thinking
steveloughran
left a comment
steveloughran
left a comment
There was a problem hiding this comment.
commented on the http/error responses. The text will become part of that API so should be made constants shared either side, and http errors raised other than for auth problems should always return something to be interpreted by users/machines
| responseBuilder.addResult(itemBuilder.build()); | ||
| } catch (NoSuchTableException | NoSuchViewException e) { | ||
| responseBuilder.addResult( | ||
| BatchLoadRelationResultItem.builder().withIdentifier(ident).withStatus(404).build()); |
There was a problem hiding this comment.
would be good to provide an explicit text/plain message for the humans here so that other causes of a 404 can be eliminated.
there's always a tradeoff here w.r.t leaking internal service state and legitimate diagnostics, but I do think there's a good case here for some text
There was a problem hiding this comment.
there is a related discussion in the spec side that we need to settle first.
#15830 (comment)
| public void accept(ErrorResponse error) { | ||
| switch (error.code()) { | ||
| case 404: | ||
| if (NoSuchNamespaceException.class.getSimpleName().equals(error.type())) { |
There was a problem hiding this comment.
and here there's code which appears to be looking into the error for classnames, which is exactly what they shouldn't be doing if it's running client side.
I think it'd be better to have a file defining those error type strings as part of the public API, give them implementation independent names ""BadRequest" over "BadRequestException" etc, and refer to them client and server. Third-party catalog impls are going to have to be generating responses which match.
There was a problem hiding this comment.
this is the existing code pattern that we probably want to follow here.
| for (BatchLoadRelationResultItem item : response.results()) { | ||
| TableIdentifier ident = item.identifier(); | ||
| switch (item.status()) { | ||
| case 200: |
There was a problem hiding this comment.
very subjective, but I'm a personal advocate of putting all refs to the http error codes in its own reference class too, so you can then use the ide to see where "SC_200" is picked up without having to search for the number.
| List<Relation> relations = Lists.newArrayList(); | ||
| for (BatchLoadRelationResultItem item : response.results()) { | ||
| TableIdentifier ident = item.identifier(); | ||
| switch (item.status()) { |
Replace hardcoded integer HTTP status codes (200, 304, 404) with HttpStatus.SC_OK, HttpStatus.SC_NOT_MODIFIED, and HttpStatus.SC_NOT_FOUND from org.apache.hc.core5.http.HttpStatus. Use Java 17 arrow-style switch in RESTSessionCatalog for cleaner control flow. Made-with: Cursor Model: claude-4.6-opus-high-thinking
2 participants
Add DTOs, parsers, handlers, and client methods for the universal relation load endpoints (GET /v1/{prefix}/namespaces/{namespace}/relations/{relation} and POST /v1/{prefix}/relations/batch-load) defined in the REST spec.
New types:
Modified:
Made-with: Cursor
Model: claude-4.6-opus-high-thinking