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

Allow typed simple filters #5760

Merged
merged 3 commits into from
Feb 26, 2023
Merged

Allow typed simple filters #5760

merged 3 commits into from
Feb 26, 2023

Conversation

zhiltsov-max
Copy link
Contributor

Motivation and context

This PR implements typed query params for simple filters, making SDK interface clearer.

How has this been tested?

Checklist

  • I submit my changes into the develop branch
  • I have added a description of my changes into the CHANGELOG file
  • I have updated the documentation accordingly
  • I have added tests to cover my changes
  • I have linked related issues (see GitHub docs)
  • I have increased versions of npm packages if it is necessary
    (cvat-canvas,
    cvat-core,
    cvat-data and
    cvat-ui)

License

  • I submit my code changes under the same MIT License that covers the project.
    Feel free to contact the maintainers if that's a concern.

@nmanovic nmanovic requested review from SpecLad and removed request for nmanovic and azhavoro February 24, 2023 09:12
Comment on lines 315 to 318
queryset = None
warnings.warn(
"{} is not compatible with schema generation".format(view.__class__)
)
Copy link
Contributor

Choose a reason for hiding this comment

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

Are there any views left that are incompatible with schema generation? Why couldn't they be adapted?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Probably, there are no such views and we can tighten this requirement.

Comment on lines 331 to 332
else:
parameter_schema = { 'type': 'string' }
Copy link
Contributor

Choose a reason for hiding this comment

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

Perhaps we should check that the field is actually a string here? If we're doing typing, it would be useful to check that the type we're applying is appropriate.

Copy link
Contributor Author

@zhiltsov-max zhiltsov-max Feb 24, 2023

Choose a reason for hiding this comment

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

Probably, these types are everything we need to support in simple filters. Basically, all fields must be serialized into strings, but we do an exception for numbers. Which other types would you like to support? To my knowledge, there are only dates that could be supported, but there are no such filters now. What is possible is that the model choice is not an integer, this is a good point.

Copy link
Contributor

Choose a reason for hiding this comment

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

My point is not that we should support other types, but that when we declare a parameter to be a string, we should check that it actually is a string. If you add an assert for that, then in the future, when someone adds a filter of a type that hasn't been used before, they will be notified that they need to update the schema generation too.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Updated

@nmanovic nmanovic merged commit 838f1da into develop Feb 26, 2023
@nmanovic nmanovic deleted the zm/allow-integer-filters branch February 26, 2023 15:19
mikhail-treskin pushed a commit to retailnext/cvat that referenced this pull request Jul 1, 2023
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