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

Refactor Lectern Validation and Parsing in preparation for conditional restrictions #217

Closed
joneubank opened this issue Jul 23, 2024 · 1 comment
Assignees

Comments

@joneubank
Copy link
Contributor

Summary of request

In preparation for implementing conditional restrictions, as planned in #209 , the validation functions need to be refactored. The particular limitation of the validation functionality is the ability to run individual restriction tests on individual fields.

Details

For conditional restrictions, each field will have a unique assortment of restrictions to apply based on the record state, therefore we need to have:

  1. function to validate single field value that takes into account the field definition and the value of its parent data record
  2. functions that validate records/schemas/dictionaries using the new field validation functions

In order to write these functions, we will need functions that perform a specific restriction test on a single field as well. The current implementation of our restriction tests take the entire data record as and then check if that test is required on each field. Refactoring this to be done on a per field basis will improve our ability to reason with testing each field separately.

Additionally, the current validation process is performed by the client functions named "processing". These are not solely performing validation, but are also parsing string values into their desired types and validating checking record structure (failing for missing or unrecognized fields). This refactor will allow us to separate this process funciton into separate and dedicated functions for parsing and validation.

Modified Interface

It is expected that this will represent breaking changes to the client API. The processing functions can be reworked to communicate errors for Parsing and Validation errors separately.

Some of the built in processing functionality includes some opinionated use of meta properties, which should also be removed.

Additionally, the previous data conversion process did not handle array fields - there was an expectation that a preprocessing step was done to separate array fields. Array parsing should now be handled by the Lectern parsing functions.

For this work, it is inteded that the Dictionary Meta Schema remains unchanged.

@joneubank joneubank self-assigned this Jul 23, 2024
@joneubank
Copy link
Contributor Author

#215

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

No branches or pull requests

1 participant