-
Notifications
You must be signed in to change notification settings - Fork 10
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
Annotate the version of an item #1041
Comments
Without |
To me, we need to introduce IDs for items. They could be a simple string interpolation |
Yes, then project.put("my_key", 3)
# Annotates the latest version by default
project.set_note("my_key", "this is 3 because 3 is good")
# Annotates version 10
project.set_note("my_key-10", "this is 3 because 3 is good") |
@augustebaum , we shouldn't add the version in the key, prefer a dedicated parameter. In your example, imagine you have two items in your project with keys I would prefer something like:
Edit: We can maybe add a new parameter to the |
agree with Thomas's solution, I like it, it seems fluid. I also like to be able to put a note at first and also afterwards. |
This is for several reasons: - it is not as explicit as several simple `put` calls: the mechanic is ambiguous with regards to atomicity (if a key-value pair is invalid, does it make the whole operation fail?) - the mechanic makes it complicated to add options to `put`, e.g. the `note` option proposed in #1041 or the `display_as` option proposed in #1045 (comment).
This is for several reasons: - it is not as explicit as several simple `put` calls: the mechanic is ambiguous with regards to atomicity (if a key-value pair is invalid, does it make the whole operation fail?) - the mechanic makes it complicated to add options to `put`, e.g. the `note` option proposed in #1041 or the `display_as` option proposed in #1045 (comment).
This is for several reasons: - it is not as explicit as several simple `put` calls: the mechanic is ambiguous with regards to atomicity (if a key-value pair is invalid, does it make the whole operation fail?) - the mechanic makes it complicated to add options to `put`, e.g. the `note` option proposed in #1041 or the `display_as` option proposed in #1045 (comment).
This is for several reasons: - it is not as explicit as several simple `put` calls: the mechanic is ambiguous with regards to atomicity (if a key-value pair is invalid, does it make the whole operation fail?) - the mechanic makes it complicated to add options to `put`, e.g. the `note` option proposed in #1041 or the `display_as` option proposed in #1045 (comment).
New methods have been added to `Project`: ```python # The default is to act on the latest version project.set_note(key, message, version=-1) project.get_note(key, message, version=-1) project.delete_note(key, message, version=-1) ``` To this end, - `Item` now has an additional attribute, `note`, which is a `str | None` - `ItemRepository` has similar methods The note related methods fail with a KeyError when the key-version combination does not exist, but: - `get_note` returns `None` if the note is `None` (no error) - `delete_note` never errors if the key-version combination exists (even if the note is already `None`, it will be set to `None` again) `set_note` fails with a TypeError if `key` or `message` is not a string. Addresses part of #1041
Is your feature request related to a problem? Please describe.
As a data scientist, I want to annotate the specific version of an item because it helps me keep track of what is happening.
As a data scientist, I want to update or delete the note I have previously created.
As a data scientist, the notes I create from the Python API must be visible in the UI.
Describe the solution you'd like
Python API
The value of the
note
kwarg is some Markdown text.Add an note:
More programmatic CRUD:
UI
Let the user interact with an item version:
Describe alternatives you've considered, if relevant
No response
Additional context
Related to #889
The text was updated successfully, but these errors were encountered: