AQL to retrieving data for an element with cardinality 0..*

[damoca (David Moner)]

Thats great! As I said before, that cl[at0005] is a valid predicate according to the AQL specifications, so it should be acceptable not only in the WHERE clause, but also in the FROM clause.

Following the discussion between @siljelb and @ian.mcnicoll, my opinion is that if we use a path in the WHERE clause, it should be evaluated as a whole, matching with every instance it finds, and without trying to break it by its middle multi-valued objects to group them. That should be explicitly expressed in the FROM clause.

[chaya]

@bna

Yes will return one row and No will return one row. As expected.

@bna please note that this has to return rows where the match is found for the two where clause in the same instance of the cluster [at0022]

[bna (Bjørn Næss)]

@chaya

please note that this has to return rows where the match is found for the two where clause in the same instance of the cluster [at0022]

Absolutely. That was the point

[Seref (Seref Arikan)]

@bna

Absolutely. That was the point

This is where I suggested that the syntax and consequently the spec is ambiguous.

@Seref

As in:

... CONTAINS INSTRUCTION i[bla] ...
... WHERE i/path/segments/all_/the/way/to/cluster/and_/its/element/value = 'foo1'
          and
          i/path/segments/all_/the/way/to/cluster/and_/its/element/value = 'foo2'

The problem above is this composition can have > 1 CLUSTERs and there’s nothing that says “a cluster should satisfy both conditions” instead, this query says “fetch me the composition that contains a cluster with criteria 1 (foo1) and also contains cluster with criteria2 (foo2)” If a composition has two clusters, each satisfying one criteria, you’ll end up selecting it, which is not what you want. (I used the underscores in the paths above to disable syntax colouring of discourse, ignore them)

Unless you introduce some mechanism that’s not in the commonly implemented subset of AQL, your best bet is to fetch these and filter the query results at the application layer.
Implementers can do different things by interpreting the same syntax in a different way, but I’m always conservative when it comes to language semantics, so I cannot see an aql level solution unless the implementation supports CLUSTER in the FROM clause

your implementation may be enforcing the criteria/logic for grouping data instances based on their archetype node ids, but I don’t think the syntax is actually expressing that here.

[ian.mcnicoll]

Hmmm … one step forward and one step back!! At least in terms of helping fix the issue.

I have picked up 2 competing themes/suggestions.

1. The ‘correct’ way to do this is enforce the grouping on a cluster by supporting CONTAINS on non-root archetype nodes. DIPS appear to do this.

2. Better and DIPS simply assume that the correct behaviour is to group data instances (as Seref just said) in the absence of such a CONTAINS clause

It would be good to hear from other CDR implementers. This is quite a critical issue as a number of archetypes now use this pattern.

[Seref (Seref Arikan)]

@ian.mcnicoll

on non-root archetype nodes

Please consider not using this term It really is vague.

[thomas.beale]

it is? Doesn’t it just mean nodes that are root points of the archetypes that created them, and are marked with the archetype id rather than an internal archetype node code. Interested to understand the ambiguity, relating to querying.

[Seref (Seref Arikan)]

@thomas.beale

Doesn’t it just mean nodes that are root points of the archetypes that created them, and are marked with the archetype id rather than an internal archetype node code

To me, that’s referring to a bunch of RM types which may be different according to interpretation. There’s been a historical difference between what can be archetyped and what the tools support (maybe that’s gone now), and what the clinicians prefer to archetype, as part of modelling. Agreeing upon a clear set of RM types as allowed types in the FROM clause is clearer to me. Highly personal view of course, but that’s where my confusion comes from.

ps: completely off topic but I’m being told that in recent years my perception has kinda “narrowed”. I seem to be getting stuck at ambiguities which do not exist to the other side of the conversation. No idea why but if this is another case, then sorry about it.

[stefanspiska]

As of the latest ehrbase Release, it will show the same behavior as Better and DIPS.

[chaya]

Thank you.

[chaya]

Hi All,
Unfortunately the latest EHRBase release has still not addressed this issue completely. I have raised an issue in EHRBase git issue.

Thanks