We could do generic rules that are parameterized by database fields, e.g.
select * from conditions;
id | part | test | minimum | maximum | equal
---|------|------|---------|----------|--------
1 | 0123 | pH | 4 | 6 | null
2 | 0123 | odor | null | null | pine
if(
(condition.equal && result === condition.equal)
|| (
(condition.minimum && result >= condition.minimum)
&& (condition.maximum && result >= condition.maximum)
)
)
return "PASS"
else
return "FAIL"
This has the potential to grow complex as we discover more user needs.
Option 2
Let users write their own judgement rules using a programming language.
e.g.:
select * from conditions;
id | part | test | judgement
---|------|------|-----------
1 | 0123 | pH | 4 < result && result < 6
2 | 0123 | odor | result == "pine"
assemble.run("sandbox")`
result = ${test.result};
print (${judgement})
`
This would effectively set up a sandboxed Docker container (running the programming language of our choice), which would then execute the user's code and return either true or false to the frontend javascript.
We wouldn't need to care what the pass/fail logic is, we just execute it and use the result.
Considerations
The first route is pretty inflexible, but it's how most problems like this are solved today. It's how LIMS currently solves the problem.
The second route is more in keeping with Assemble's architecture: it blurs the line a bit between user-defined behavior and application logic.
The first one would take longer to implement and would require more maintenance as customer needs change.
The second one would mean a bigger learning curve for whoever defines the tests. This is mitigated a bit because:
There's only one person who defines tests currently
We can let them define rules in whatever language they like
Option 2 feels a bit cleaner to me, and would give us more chances to consider Assemble-as-a-platform features & issues.
c-lliope
commented
6 years ago
We've got a couple options for this.
Option 1
We could do generic rules that are parameterized by database fields, e.g.
This has the potential to grow complex as we discover more user needs.
Option 2
Let users write their own judgement rules using a programming language.
e.g.:
This would effectively set up a sandboxed Docker container (running the programming language of our choice), which would then execute the user's code and return either
trueorfalseto the frontend javascript.We wouldn't need to care what the pass/fail logic is, we just execute it and use the result.
Considerations
The first route is pretty inflexible, but it's how most problems like this are solved today. It's how LIMS currently solves the problem.
The second route is more in keeping with Assemble's architecture: it blurs the line a bit between user-defined behavior and application logic.
The first one would take longer to implement and would require more maintenance as customer needs change.
The second one would mean a bigger learning curve for whoever defines the tests. This is mitigated a bit because:
Option 2 feels a bit cleaner to me, and would give us more chances to consider Assemble-as-a-platform features & issues.
Thoughts?