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

Update TableConfigCollection to add GemdQuery config generator #967

Merged
merged 3 commits into from
Oct 1, 2024

Conversation

kroenlein
Copy link
Collaborator

@kroenlein kroenlein commented Oct 1, 2024

Citrine Python PR

Description

This is a sub-element for supporting https://github.com/CitrineInformatics/platform-backend/pull/4731. This implements existing aspects of the API, and corrects some minor inconsistencies in the existing GemdQuery implementation.

PR Type:

  • Breaking change (fix or feature that would cause existing functionality to change)
  • Bug fix (non-breaking change which fixes an issue)
  • New feature (non-breaking change which adds functionality)
  • Maintenance (non-breaking change to assist developers)

Adherence to team decisions

  • I have added tests for 100% coverage
  • I have written Numpy-style docstrings for every method and class.
  • I have communicated the downstream consequences of the PR to others.
  • I have bumped the version in __version__.py

@kroenlein kroenlein requested a review from a team as a code owner October 1, 2024 04:38
lower = properties.Float('lower')
upper = properties.Float('upper')
lower = properties.Integer('lower')
upper = properties.Integer('upper')
Copy link
Contributor

Choose a reason for hiding this comment

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

I was taking a look at the AllIntergerFilter case class in the backend, and it looks like it has a field called inclusive which defaults to true. Was that omission on purpose? I wonder if it is the case that it doesn't add value.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I'd missed that. I'll add it here as well. 🙇

are expressed as Bounds. Attributes are expressed with links. The attribute that the
variable is being set to may be the target of a constraint as well.
type_selector: DataObjectTypeSelector
strategy for selecting data object types to consider when matching, defaults to PREFER_RUN
Copy link
Contributor

Choose a reason for hiding this comment

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

Just double-checking, Here we are not mapping attribute_template_type, I do see it in the openapi spec, is this because we are not going to use it on the SDK?

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

It is in the openapi spec, but that field is not populated by any of the existing Variable objects in the SDK. For the life of me, I don't see what impact that field is supposed to have, based on digging through platform-backed.

@@ -552,7 +638,7 @@ def preview(self, *,
List of links to the material runs to use as terminal materials in the preview

"""
path = path = format_escaped_url(
Copy link
Contributor

Choose a reason for hiding this comment

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

Nice catch

register_config=True
)
assert session.num_calls == len(query['datasets']) + 1 + 1
assert generated != TableConfig.build(config) # Because it has ids
Copy link
Contributor

Choose a reason for hiding this comment

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

Is there any code change that can be introduced to falsify this assertion? I'm just curious about why you are validating it. It might be obvious but I'm not super familiar with this.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

The table config returned by the registration route augments the table config returned by the from_query route by adding registration metadata to the object (id, version number...). This is making sure that when you flip the register_config flag, you get the return of the register route, not the from_query route.

In theory, this test could be rewritten as The table config has meta data, and if I ignore it, then they are the same but I don't think that adds meaningful additional coverage.

pacdaemon
pacdaemon previously approved these changes Oct 1, 2024
Copy link
Contributor

@pacdaemon pacdaemon left a comment

Choose a reason for hiding this comment

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

I left a few comments, but other than that it looks good. If there is a need for addressing any of the concerns feel free to ping me for a second round, otherwise feel free to merge it.

Comment on lines +369 to +370
attribute_constraints = properties.Optional(
properties.List(
Copy link
Collaborator

Choose a reason for hiding this comment

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

Are null and [] actually treated differently by the backend? If not, I'd suggest there's no need to make this Optional.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I don't disagree, but every existing Variable in the SDK uses this pattern.

Comment on lines 58 to 59
lower = properties.Float('lower')
upper = properties.Float('upper')
lower = properties.Integer('lower')
upper = properties.Integer('upper')
Copy link
Collaborator

Choose a reason for hiding this comment

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

You know my thoughts on this from our argument two weeks ago: changing types is an interface break. This is a mild one, as I can't think of a standard operation it would break, since Python's standard division always returns a float, and I'm unsure why a user would do something like isinstance(value, float). But it nonetheless gets into the business of assuming which interface breaks the user cares about, which is a Bad Idea.

I've no intention of wasting more energy on such a petty problem, but I also won't be approving this PR as long as it's left in. Seeing as there are other approvers, and you've already got one from Pablo, it won't stand in your way.

Copy link
Collaborator Author

Choose a reason for hiding this comment

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

I have reverted this fix, as it was tangential to the actual goal of the PR.

In this case, this is not a breaking change because the GemdQuery API is fundamentally broken and does not support any filters, so no user workflow could actually depend on this behavior.

@kroenlein kroenlein merged commit 510152d into main Oct 1, 2024
16 checks passed
@kroenlein kroenlein deleted the feature/table-config-from-query branch October 1, 2024 19:35
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.

3 participants