SELECT c/uid/value, instruction
FROM EHR e[ehr_id/value=$ehrid]
CONTAINS COMPOSITION c
CONTAINS INSTRUCTION instruction[openEHR-EHR-INSTRUCTION.referral.v1]
WHERE EXISTS instruction/links[target='ehr://327000002/87284370-2D4B-4e3d-A3F3-F303D2F4F34B@latest_trunk_version']
When I reduce this query to
SELECT e FROM EHR e[ehr_id/value=$ehrid]
why is the constraint on the ehr_id done in the FROM section and not in the WHERE section like
Given the AQL syntax and its current specifications, nothing stops you from using the WHERE clause. However, you should consider the consequences of using the WHERE clause to express that constraint.
if you’d like to express any other criteria such as a particular DV_QUANTITY/magnitude value being greater than x (…/magnitude >= x) this will go WHERE clause as well. Since multiple constraints in the WHERE clause have to be connected by logical operators, you now have to write:
WHERE e/ehr_id/value = $ehrId AND c/…/magnitude >= x
so you’ll have to express the implicitly stated (when you use [ehr_id/value=..] AND condition explicitly and think about that logic. I’d say it is possible that this will lead to bugs especially in complicated AQL queries.
the second reason, which is pure speculation: is that some back ends are likely to have mechanisms that process different constraints in an AQL query in different ways. Pretty similar to query planners in relational databases. The back end you’re using may end up selecting all ehrs(!) and then applying a filter due to ehr id constraint being in the WHERE clause. This may or may not be the case, but I would not risk it.
Finally, to make things even more complicated, as per the predicates section of aql spec ( https://www.openehr.org/releases/QUERY/latest/docs/AQL/AQL.html#_predicates ), there is nothing that stops you from moving a constraint in the WHERE clause into the FROm clause (in some cases). Why? Because both archetype and node predicates are syntactic sugar for standard predicate. So if you have a standard predicate such as the dv_quantity example I gave you above, you could move it into FROM clause as follows:
… COMPOSITION c[/bla/bla/bla/magnitude >= x] CONTAINS bla bla
But in that case you would not be able to express boolean operations where the operands are constrains of the nodes in the FROM clause. That’s why I said in some cases above.
My suggestion: stick to conventions as much as you can, there is quite a bit of flexibility in the AQL syntax and its semantics is not formally defined (as in no formal backing model of queries and match operation etc) and you don’t want to fall into those cracks. You may get wrong results due to interpretation differences between vendors and your queries may lose portability.