Join GitHub today
GitHub is home to over 40 million developers working together to host and review code, manage projects, and build software together.Sign up
Domain entities #10437
This is the core domain entities PR. It adds all the parsing and binding machinery and plugs DE into transforms. The followup PR will infer DEs during sync and persist them (this is currently done manually in transforms).
One thing I'm not sure about is if it's correct to enforce that fields that are required are specified by their type -- or -- that transforms check their outputs against the domain entity spec. Perhaps the correct approach is for transforms to have custom validation of results which treats dimension names as (also) types. However that will also necessitate relaxing the schema for DE spec in that it will no longer check if a given
Note: for clarity this PR is based on #10105
Another thing I was thinking about:
The QP store is really just an internal cache used by the QP for the duration of a query execution and using it in non-QP related code really creates messy dependencies between different modules that I think are a clear sign we're doing something wrong. Calling individual pieces of QP middleware separately isn't generally something that should ever be needed outside of the QP itself. If it is needed somewhere else, we should consider whether that sort of stuff can be moved into the MBQL library itself or elsewhere.
Generally I don't think this code should be using any QP code besides the public interface in
salsakran left a comment
I take it back, in looking at #10457, I think we should have a different name for the resource/domain_entities and the instantiated domain entities that are persisted to the application DB in that PR.
I think we settled on something like "domain entity specs" or something similarly horrible (but clear).