Skip to content
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

[DOGE-15] Update Sequence Issue #2057

Merged
merged 11 commits into from
Dec 12, 2024
Merged

[DOGE-15] Update Sequence Issue #2057

merged 11 commits into from
Dec 12, 2024

Conversation

doctrino
Copy link
Contributor

@doctrino doctrino commented Dec 4, 2024

Description

Please describe the change you have made.

Checklist:

  • Tests added/updated.
  • Documentation updated. Documentation is generated from docstrings - these must be updated according to your change.
    If a new method has been added it should be referenced in cognite.rst in order to generate docs based on its docstring.
  • Changelog updated in CHANGELOG.md.
  • Version bumped. If triggering a new release is desired, bump the version number in _version.py and pyproject.toml per semantic versioning.

@doctrino doctrino marked this pull request as ready for review December 4, 2024 14:18
@doctrino doctrino requested review from a team as code owners December 4, 2024 14:18
Copy link

codecov bot commented Dec 4, 2024

Codecov Report

Attention: Patch coverage is 89.13043% with 5 lines in your changes missing coverage. Please review.

Project coverage is 90.49%. Comparing base (29408d2) to head (d15ec32).
Report is 1 commits behind head on master.

Files with missing lines Patch % Lines
cognite/client/_api/sequences.py 87.50% 5 Missing ⚠️
Additional details and impacted files
@@            Coverage Diff             @@
##           master    #2057      +/-   ##
==========================================
- Coverage   90.50%   90.49%   -0.01%     
==========================================
  Files         141      141              
  Lines       22493    22533      +40     
==========================================
+ Hits        20357    20392      +35     
- Misses       2136     2141       +5     
Files with missing lines Coverage Δ
cognite/client/_api/annotations.py 95.65% <100.00%> (ø)
cognite/client/_api/hosted_extractors/sources.py 94.02% <100.00%> (ø)
cognite/client/_api_client.py 90.34% <100.00%> (ø)
cognite/client/_version.py 100.00% <100.00%> (ø)
cognite/client/data_classes/sequences.py 90.69% <ø> (ø)
cognite/client/_api/sequences.py 95.21% <87.50%> (-1.47%) ⬇️

Copy link
Contributor

@haakonvt haakonvt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Great that you are addressing this one! We should decide on how we want to solve the general problem of not-updateable-fields for write-classes in general. Have you done some thinking around this in light of this PR?

cognite/client/_api/sequences.py Outdated Show resolved Hide resolved
Comment on lines +720 to +721
# String is not recognized as hashable by mypy
cdf_item_by_id=cdf_item_by_id, # type: ignore[arg-type]
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not just use dict[str, T_WritableCogniteResource]?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not all identifiers are string. Workflow and data modeling are two examples that uses frozen dataclasses.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Oh right, makes sense. Then you must use Mapping/MutableMapping which is covariant (dict is invariant)

cognite/client/_api/sequences.py Show resolved Hide resolved
Comment on lines 747 to 751
if to_remove := (set(cdf_columns_by_external_id.keys()) - set(columns_by_external_id.keys())):
update_obj["update"]["columns"]["remove"] = list(to_remove)
if to_add := (set(columns_by_external_id.keys()) - set(cdf_columns_by_external_id.keys())):
update_obj["update"]["columns"]["add"] = [columns_by_external_id[ext_id].dump() for ext_id in to_add]
if to_modify := (set(columns_by_external_id.keys()) & set(cdf_columns_by_external_id.keys())):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This doesn't seem to distinguish based on mode ("replace_ignore_null", "patch", "replace")?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are right, good catch. Since columns are not nullable, I think replace and 'replace_ignore_null' should be the same behavior. While patch should not do the remove.

tests/tests_integration/test_api/test_sequences.py Outdated Show resolved Hide resolved
@doctrino doctrino requested a review from haakonvt December 11, 2024 09:56
@@ -730,7 +730,7 @@ def _convert_resource_to_patch_object(
cdf_item_by_id: dict[str, Sequence] | None = None, # type: ignore[override]
) -> dict[str, dict[str, dict]]:
update_obj = super()._convert_resource_to_patch_object(resource, update_attributes, mode)
if not isinstance(resource, SequenceWrite):
if not isinstance(resource, SequenceWrite) or not resource.columns:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

...but if mode=="replace", empty columns should mean remove, right?

Copy link
Contributor Author

@doctrino doctrino Dec 12, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Good point, but columns are required, so will just remove the check. So you cannot set them to null.

@haakonvt
Copy link
Contributor

There's still this question left from initial review:

We should decide on how we want to solve the general problem of not-updateable-fields for write-classes in general. Have you done some thinking around this in light of this PR?

@doctrino
Copy link
Contributor Author

There's still this question left from initial review:

We should decide on how we want to solve the general problem of not-updateable-fields for write-classes in general. Have you done some thinking around this in light of this PR?

I consider that a separate topic apart from this PR. It is on my list of todos, but cannot be solved in this one.

@doctrino doctrino requested a review from haakonvt December 12, 2024 08:34
@haakonvt
Copy link
Contributor

This PR breaks the example given in the docstring for client.sequences.upsert:

from cognite.client.data_classes import Sequence

client.sequences.upsert(
    Sequence(external_id="new_sequence", description="New sequence")
)

@haakonvt
Copy link
Contributor

haakonvt commented Dec 12, 2024

Maybe, when I think about it, upsert should actually enforce that columns is set because if it doesn't exist (update failed), it will be created and then it is required from the API. So I suggest we just change the docstring example instead. Wdyt?

@doctrino
Copy link
Contributor Author

Maybe, when I think about it, upsert should actually enforce that columns is set because if it doesn't exist (update failed), it will be created and then it is required from the API. So I suggest we just change the docstring example instead. Wdyt?

Agreed.

Copy link
Contributor

@haakonvt haakonvt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@doctrino doctrino merged commit caeee0d into master Dec 12, 2024
16 checks passed
@doctrino doctrino deleted the update-sequence-issue branch December 12, 2024 11:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants