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

DM-47769: Refactor Wobbly schema to support Pydantic #11

Merged
merged 1 commit into from
Nov 25, 2024
Merged

Conversation

rra
Copy link
Member

@rra rra commented Nov 23, 2024

Instead of writing an explicit object conversion function, rework the Wobbly schema so that ORM objects can be converted directly to Pydantic objects using model_validate. This requires moving the ordering of results into the ORM rather than doing it manually, moving the error attributes into a table and allowing more than one error, and reworking the schema for results to avoid an autogenerated key that clashes with the client-provided result ID.

UWS does not allow multiple errors in the current schema, but any revision of the standard should ideally support multiple errors. For now, we can follow the convention of storing at most one error and not use this schema functionality, but since it makes the Pydantic integration easier, it seemed better to future-proof now.

Change the cascade configuration of the job ORM model to ensure that any orphaned result or error objects are deleted, which was already required by the schema.

@rra rra requested a review from fajpunk November 23, 2024 00:58
@rra
Copy link
Member Author

rra commented Nov 23, 2024

This is required to use the new Safir pagination support, since it requires direct conversion to a Pydantic model. (And really I should have done it this way all along. I was just lazy and copied the pattern from vo-cutouts.

Instead of writing an explicit object conversion function, rework
the Wobbly schema so that ORM objects can be converted directly to
Pydantic objects using `model_validate`. This requires moving the
ordering of results into the ORM rather than doing it manually,
moving the error attributes into a table and allowing more than one
error, and reworking the schema for results to avoid an autogenerated
key that clashes with the client-provided result ID.

UWS does not allow multiple errors in the current schema, but any
revision of the standard should ideally support multiple errors.
For now, we can follow the convention of storing at most one error
and not use this schema functionality, but since it makes the
Pydantic integration easier, it seemed better to future-proof now.

Change the cascade configuration of the job ORM model to ensure that
any orphaned result or error objects are deleted, which was already
required by the schema.
@rra rra merged commit 77a89f5 into main Nov 25, 2024
3 checks passed
@rra rra deleted the tickets/DM-47769 branch November 25, 2024 17:03
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