-
Notifications
You must be signed in to change notification settings - Fork 2
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
Add conditional restrictions to dictionary fields #198
Conversation
| Restriction | Used with Field Types | Type | Description | Examples | | ||
| ----------- | ----------------------------- | --------------------------------------------------------------- | :------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- | | ||
| `codeList` | `integer`, `number`, `string` | Array of type of the field | An array of values of the type matching this field. Data provided for this field must have one of the values in this list. | `["Weak", "Average", "Strong"]` | | ||
| `compare` | all | [ComparedFieldsRule](#comparedfieldsrule-data-structure) object | Enforces that this field has a value based on the provided value in another field. Examples would be to ensure that the two values are not equal, or for numeric values ensure one is greater than the other. | `{ "fields": ["age_at_diagnosis"], "relation": "greaterThanOrEqual" }` Ensure that a field such as `age_at_death` is greater than the provided `age_at_diagnosis` | |
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.
Example uses greaterThanOrEqual
.
But don't see this value in:
https://github.com/overture-stack/lectern/blob/da452d4dc016daa15738988d804547e47dfcc872/libraries/dictionary/README.md#comparedfieldsrule-data-structure
Also snakecase or camelcase?
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 want to consistently use camelCase for json properties. for constant values like "greaterThan" we could use upper snake case instead to indicate they are constant values: GREATER_THAN
I might've missed this property in the docs, thanks for pointing it out.
libraries/dictionary/README.md
Outdated
> } | ||
> ``` | ||
|
||
A `meta` object is available to allow the dictionary creator to add custom properties to the Lectern Dictionary. The `meta` property is available to all Dictionary, Schema, and Field objects. Providing a `meta` value is optional, but if provided it must be a JSON object. There are no restrictions on the field names that can be added to the `meta` object other than they must be valid JSON. The values for meta properties are restricted to being a `string`, `number`, or `boolean` value. This means that meta data cannot be nested or accept arrays. |
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 means that meta data cannot be nested or accept arrays
.
Is this due to a technical limitation?
For PCGL currently this is the "workaround" ( a string mimicing an array of dictionary objects):
https://github.com/Pan-Canadian-Genome-Library/data-dictionary/blob/71fee8cc4cb2db40ec2e747f297a2ba9d2401e73/schemas/participant.json#L46C11-L46C148
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.
ok good feedback, string parsing is way worse... we were trying to keep this for simple usage and known property names... this shows you want to use it with any number of unknown properties. this can be changed I think.
Would the following be an appropriate usage:
|
@edsu7 looks semantically correct. The rules for this would be that when That doesn't make sense for a field titled |
A couple of more examples - to mimic
|
@edsu7 Replying to your examples. They seem to be mismatched with the links you gave so I'll interpret what you wrote and if that is what you expected then we're good!
{
"restrictions": {
"if" : {
"conditions": [
{
"fields": ["submitter_primary_diagnosis_id","submitter_treatment_id","submitter_follow_up_id","test_interval"],
"match": {"exists":true},
"case":"any"
}
],
},
"then" : {
"empty": true
},
"else" : {
"required": true,
"regex": "^[A-Za-z0-9\-\._]{1,64}$"
}
}
} |
617eb89
to
6b9b4a5
Compare
b7a7ad8
to
cbe0f7a
Compare
Closing this PR as these changes were made before significant refactoring of the code base. The relevant changes will be replicated into a new feature branch based on the latest develop branch. The proposed conditional restrictions spec has been committed to the main code base as part of the dictionary reference doc |
Implement conditional restrictions as described in: #199 Epic: Conditional Restrictions
This feature branch will collect the work for each part of the project as described in the linked Epic, once all parts are available it can be merged as a complete feature into the primary branch.
The outcome of this feature will be to have conditional restrictions available for fields in Lectern Dictionaries, and the script restrictions no longer available. This applies both to the dictionaries maintained by the lectern schema, and the validation implementation provided by the lectern client.
Breakdown
script
restriction