@thomas.beale I’m taking back my suggestion of SET X /UNSET X. It is a bad idea. As I wrote above, this approach has multiple problems:
- Its binary nature is not sufficiently clear for potentially multi-dimensional behaviour choices. Even in RDMSs, where the context is simpler, this approach is leading to lots of problems.
- It binds runtime behaviour to actual data. Whether or not we do it with SET switches does not matter. This’ll create a backdoor to a bad design choice and requests will start piling up; every clinician with a ‘magical’ wish will get in the queue with their boolean flags instead of writing WHERE clauses:
We’ll be trying to explain to clinicians whySET HIDE_NOT_CODED_DIAGNOSIS ONis a bad idea within a few months .
What we can do is to introduce ‘semantic-safety’ to AQL, similar to how static type checking works. This is me thinking on @birger.haarbrandt 's response to my request for clarification.
As @ian.mcnicoll says, my suggestion to write the where clauses can be problematic because users of AQL are prone to forgetting to do that (I’ll forget the proper uses/improper uses section of archetype metadata for the moment). Ok, then we force the CDRs and modelling tools to remind the users to write the WHERE clause or path predicate (as Birger suggested).
This leaves all the runtime behaviour as it is, we can make the suggestions as complicated as it needs to be and we handle to whole requirement above the AQL runtime. If the modelling tool can’t catch it, then the CDR would during query parse.
If a CDR doesn’t support this feature, it is not different than someone forgetting to type SET X ON but this approach leaves runtime unmodified/simple and is more expressive than binary flags.
Now, how do we define these semantic-safety rules and where do we put them (ideally into a template that includes this extra semantic constraint) is another discussion but I’ll cross this bridge once I win some ground with this binary flag thing 
Thoughts?