Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Model Versions are taggable #2102
Model Versions are taggable #2102
Changes from 2 commits
7d22b1d
92303b1
13c3a72
86228eb
64958e4
2896e6d
2066a70
10ccecb
568a1c4
b9d4842
110c2ba
951143b
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Also a general question here: I started seeing this pattern with the other taggable entities as well. In the earlier iterations, we have used the
update
method of aSchema
to apply such changes. Lately, I see that the update is happening one layer up on the SqlZenStore level instead of the Schema level. Is there a reason why we see this switch when it comes to models and artifacts?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.
Not sure that there is a real explanation behind that. Can you share some Schemas having such "extended" updates? For instance in
run_metadata
we use an extra method to create those, so it is not really closely coupled with the object itself (e.g.create_run_metadata
is called as one of the steps insave_artifact
utility).It might turn out that having those very related entities coupled in one update method is a bit better choice, IMO. But it is definitely not a battle I want to fight in, so if you share examples and reject my explanations - I will rework 👍🏼
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.
I think in their first iterations, most schemas had an
update
function which was relatively more extended. However, as I went through the current implementation, I see that this is not the case anymore. I don't think we need to rework anything in the scope of this PR though, ideally, this would be a separate cleaning-up ticket in the future.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.
If we need examples in any case:
This is the inconsistency that I find suboptimal. IMO, the update should either happen fully on the
SQLZenStore
or fully on theupdate
method of a schema. Otherwise, the code becomes very hard to track and read.