FANNG1 commented on PR #12424:
URL: https://github.com/apache/gravitino/pull/12424#issuecomment-5339626476
Thanks for the detailed responses — treating metalake-wide discovery as a
separate reusable search capability, and keeping the Ossie projection internal,
both make sense to me.
One question and one input case below.
**Value-level semantics have nowhere to live.** A subscriber table has a
`type` column where `0` and `1` encode two consumer brands. A user asks for
"brand-B subscribers"; the knowledge that answers it is `type = 1`, and the
contract has no place to record it. Against the pinned schema (`88e0011`),
`Field` and `Dimension` are both `additionalProperties: false`, and none of the
13 `$defs` is a segment, filter, or value-mapping concept. A model can say
`type` exists and is an `Integer` — not what its values mean.
The workarounds are a `CASE WHEN` inside an expression string Gravitino does
not interpret, a dimension table that often does not exist, or an invented
`ai_context` key.
This matters most for the agent path because the failure is silent: a wrong
guess at `type = 1` returns the other brand's rows — valid SQL, plausible
shape, wrong number. Going through a dimension table at least fails visibly
with an empty result.
This is an upstream Ossie gap rather than a flaw here, and its assumption
that code semantics resolve into dimension tables is defensible. But since this
design already preserves `ai_context` and `custom_extensions`, it could
recommend a convention — say a field-level `ai_context.value_labels` as
`{value: label}` — so the encoding is at least consistent within a deployment
instead of every producer inventing its own key. Worth raising upstream too.
**Is the intent to follow Ossie strictly?** The revision replaces the closed
`Dialect` enum with open strings, validates against "a Gravitino profile
derived from" the pinned schema, and limits upstream validation tools to
fixtures that use Ossie-defined dialects. A model carrying a `trino` dialect is
therefore valid in Gravitino and invalid against upstream Ossie. Is that a
deliberate one-off, or the start of a profile that may diverge wherever Ossie
constrains a real Gravitino use case?
The answer decides how the case above should be handled — an `ai_context`
convention stays inside the spec's own extension point, while a profile-level
field would not — and it decides what "Ossie-compatible" in Goal 4 promises
users. Either direction seems reasonable; it would help for the document to
state the compatibility boundary explicitly, including which subset is expected
to validate upstream.
--
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]
