-
Notifications
You must be signed in to change notification settings - Fork 14
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add exports config to YAML spec for saved queries #190
Conversation
@@ -18,3 +18,6 @@ test: | |||
|
|||
lint: | |||
hatch run dev-env:pre-commit run --show-diff-on-failure --color=always --all-files | |||
|
|||
json_schema: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This make target was mentioned in CI, but it didn't actually exist in the repo so I added it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This all seems reasonable to me, but since I wasn't at the final design sync I'll defer to one of those folks for final approval.
|
||
@property | ||
@abstractmethod | ||
def schema_name(self) -> Optional[str]: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@QMalcolm the core parser can take schema
from yaml and convert it to schema_name just as we do with Pydantic here, correct? I'm assuming that's the case.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is indeed the case. We have a separate unparsed and parsed node representation. It'll be schema
in the unparsed and schema_nam
e in the parsed
assert export2_config.schema_name is None | ||
assert export2_config.alias is None |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Question for the folks who designed the spec - do we want to allow this? It seems like we can't actually fulfill this contract because there's no way to tell a warehouse "here, put this data..... someplace."
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Note - if this will be caught by a validation PR I haven't read yet, just tell me to go away. :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What about the table name? Or is the table name the export name? Is that obvious to people?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yep it will default to the export name. I have no idea if that's obvious to people but it should be in the docs when we get to that
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me! Thanks for doing this work 🙂
Resolves #189
Description
Adds
exports
YAML options to the spec forsaved_queries
.Checklist
changie new
to create a changelog entry