-
Notifications
You must be signed in to change notification settings - Fork 3
VED-909: Uplift Schema Expression Rule #982
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
base: staging/VED-508-validation-refactor-and-dq-feature
Are you sure you want to change the base?
VED-909: Uplift Schema Expression Rule #982
Conversation
|
This branch is working on a ticket in the NHS England VED JIRA Project. Here's a handy link to the ticket: VED-909 |
|
JamesW1-NHS
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
just a few issues.
NB: though the operation of the validator is dependent on fields in the schema, we're not testing explicitly for an error when checking a field that we know is not present in the schema. test_postcode_string_rule_valid_and_invalid() sort of does it (with field_path = POST_CODE) but it's by accident rather than on purpose.
I assume that we expect the FHIR validator to deal with those?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where are these schema files used?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
these files would be used as schema files per environment, not populated yet as it is meant to be used when we have a fully functional schema that we can use per environment,
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Where is this file used?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
same
| expression_values = data_parser.extract_field_values(expression_fieldname) | ||
| print(f"Validating Expression ID {expression_fieldname} with values: {expression_values}") | ||
| except Exception as e: | ||
| message = f"Data get values Unexpected exception [{e.__class__.__name__}]: {e}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd make the message "Extract Field Values: Unexpected exception ..." - it's better English and more consistent with the function naming
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
for testing but would ultimatelty remove it eventually
| row += 1 | ||
| return row | ||
| except Exception as e: | ||
| message = f"Expression Validation Unexpected exception [{e.__class__.__name__}]: {e}" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd make the message "Validate Expression: Unexpected exception ..." (see above)
| except Exception as e: | ||
| message = f"Expression Validation Unexpected exception [{e.__class__.__name__}]: {e}" | ||
| error_record = ErrorReport(code=ExceptionLevels.UNEXPECTED_EXCEPTION, message=message) | ||
| error_record = ErrorReport(code=ExceptionLevels.PARSING_ERROR, message=message) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We're overwriting the error_record written in the previous line.
Do we want to add both of these in add_error_record()?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Question: should backend (and later recordprocessor) unit tests also use this schema when creating a Validator?
| "9876543210", | ||
| ) | ||
| ) | ||
| self.assertIsNone( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a duplicate of lines 28-35
| # With empty rule, generic string constraints apply: non-empty and no spaces | ||
| self.assertIsNone(checker.validate_expression("STRING", "", field_path, "SW1A 1AA")) | ||
| # Real-world postcode with a space should fail as spaces are not allowed without a rule override | ||
| field_path = "POST_CODE" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I can't see POST_CODE in the test schema anywhere, did you mean PERSON_POSTCODE?
| field_path = "contained|#:Patient|address|#:postalCode|postalCode" | ||
| # With empty rule, generic string constraints apply: non-empty and no spaces | ||
| self.assertIsNone(checker.validate_expression("STRING", "", field_path, "SW1A 1AA")) | ||
| # Real-world postcode with a space should fail as spaces are not allowed without a rule override |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should we then add a test for that e.g.
self.assertIsInstance(
checker.validate_expression("STRING", "PERSON_POSTCODE", field_path, "SW1A 1AA"),
ErrorReport,
)
|
Work has been paused on this approach. Worth considering closing the PR. Especially if we get a clear outcome from VED-947 which results in us redesigning the approach. |



Summary
Add any other relevant notes or explanations here. Remove this line if you have nothing to add.
Reviews Required
Review Checklist
ℹ️ This section is to be filled in by the reviewer.