[PNE-6647] Tag default DS with settings object.#992
Conversation
There was a problem hiding this comment.
My local machine raised flake8 failures without these blank lines. ¯_(ツ)_/¯
anoto-moniz
force-pushed
the
feature/pne-6647-ds-store-default-settings
branch
2 times, most recently
from
784af3a to
e192151
Compare
|
|
||
| """ | ||
|
|
||
| _settings = properties.Optional(properties.Object(DesignSpaceSettings), "metadata.settings") |
There was a problem hiding this comment.
These settings are just metadata intended to be carried to DS registration, not for users to tinker with. The only effect messing with them will have is screwing up filtering in the UI.
|
|
||
| """ | ||
|
|
||
| _settings = properties.Optional(properties.Object(DesignSpaceSettings), "metadata.settings") |
| if self._settings: | ||
| data["settings"] = self._settings.dump() |
There was a problem hiding this comment.
Note that for registration, they're added in a different place than they're read. This is intentional.
| if self._settings: | ||
| data["settings"] = self._settings.dump() |
| CreationType = TypeVar('CreationType', bound=DesignSpace) | ||
|
|
||
|
|
||
| class DefaultDesignSpaceMode(BaseEnumeration): |
There was a problem hiding this comment.
Although the class definition is moved, since it's still being imported here, it will not break user imports.
| dsc.delete(uuid.uuid4()) | ||
|
|
||
|
|
||
| def test_carrying_settings_from_create_default(valid_product_design_space): |
There was a problem hiding this comment.
This and the following test check the new behavior explicitly.
When creating a design space, the endpoint accepts a dict of the settings which were used to create it. To make this process transparent from a user perspective, any design space which is created with create_default will have the settings dict attached to it in non-public field. So when the user goes to register it, the settings object will automatically be included. Additionally, when retrieving a design space from the backend, those settings are part of the metadata. They will be captured in a non-public field, so if a user turns around and registers the design space object again, this copy will contain those settings.
anoto-moniz
force-pushed
the
feature/pne-6647-ds-store-default-settings
branch
from
e192151 to
1069baa
Compare
kroenlein
left a comment
kroenlein
left a comment
There was a problem hiding this comment.
This looks good. I kinda wish the DesignSpaceSettings objects were in factories.py, but that is not strictly necessary.
Isn't factories.py only on the |
2 participants
Citrine Python PR
When creating a design space, the endpoint accepts a dict of the settings which were used to create it. To make this process transparent from a user perspective, any design space which is created with create_default will have the settings dict attached to it in non-public field. So when the user goes to register it, the settings object will automatically be included.
Additionally, when retrieving a design space from the backend, those settings are part of the metadata. They will be captured in a non-public field, so if a user turns around and registers the design space object again, this copy will contain those settings.
Description
Please briefly explain the goal of the changes/this PR.
The reviewer should be able to understand why the change is being made by reading this description
and its links (e.g. JIRA tickets).
PR Type:
Adherence to team decisions