Hi Pablo, see inline please On Mon, Oct 8, 2018 at 8:29 PM Pablo Pazos <pablo.pa...@cabolabs.com> wrote:
> Recently we discussed other problematic cases, like having criteria over a > structured datatype like: > > WHERE xxxx/data[at0001]/items[at0004]/value/magnitude >= 140 AND > xxxx/data[at0001]/items[at0004]/value/units = "mmHg" > > Internally that should be interpreted as "magnitude" and "units" should be > attributes of the same DV_QUANTITY instance, but do all AQL implementations > actually do that? > Who knows? :) the syntax is correct though, so what they do internally does not matter, the WHERE clause is clearly introducing two constraints on the same DV_QUANTITY instance. > > > But maybe that kind of query should be written as: > > WHERE dv/magnitude >= 140 AND dv/units = "mmHg" > > In that case, dv should be defined in the FROM, and all variables/aliases > should point to the same data instance. > this is also valid AQL but you may have two problems here: 1) AQL implementations may not support the full AQL semantics. That is, even though EHR e[..] CONTAINS DV_QUANTITY dv is legal AQL a particular back end may not support it. In your example snippet, the FROM statement (which we don't see) should have an xxxx. Now to use the dv alias as you've suggested, that FROM claused would have to become: xxxx/data[at0001]/items[at0004]/value as dv and this is the case a back end may not support, or all back ends may not support because a common thinking among vendors is users would select more meaningful/high-level nodes (mostly entries or clusters under them) and access data via SELECT or apply criteria in WHERE clauses using relative paths. 2) if you'd like to apply two criteria to xxxx, then you have to declare xxxx in FROM clause and do WHERE xxx/path1/value <criteria> AND xxx/path2/value <criteria> So you have to define xxxx here, if you do what I described above, you only have DV_QUANTITY leaf node and you cannot introduce constraints to other nodes relative to xxxx. So you have pros and cons or 'high level nodes giveth and taketh away'... Another option, which should actually be legal given the current AQL grammar may be to move all constraints on xxx to the immediate predicate of xxxx but this should be used only when there is no ambiguity. As in: FROM ..... CONTAINS xxxx[data/items/value/magnitude >= 140 AND data/items/value/units = 'mmHg'] This would neatly move the joint criteria up but I would be uncomfortable with this because you cannot specify archetype node ids for data[]/items[] anymore and this would likely trigger a cartesian explosion in result sets. Then you'd have Ian complaining about duplicate results ;) All the best Seref > On Mon, Oct 8, 2018 at 3:06 PM Georg Fette <georg.fe...@uni-wuerzburg.de> > wrote: > >> Hello, >> I have another question concerning the semantics of AQL queries: >> In the documentation there are queries of the form >> SELECT a/data[at0001]/items[at0004]/value >> FROM EHR e CONTAINS COMPOSITION a[openEHR-EHR-COMPOSITION.encounter.v1] >> WHERE b/data[at0001]/items[at0004]/value/value >= 140 >> What ensures that the identified path in the SELECT section references >> the same data instances that are contrained with the same identified >> path in the WHERE section ? It could be argued that there is only one >> "data[at0001]" in "b" and only one "items[at0004]" in "a/data[at0001]" >> and so on. But is this already the full explanation for the expression >> to be unambiguous ? The aliases used in queries (e.g. "a") ensures that >> a reference to an alias definitely means the same instance. Looking at >> queries like the one above let assume that aliases are only syntactic >> sugar and are not functionally needed. Is this correct ? >> Greetings >> Georg >> >> -- >> --------------------------------------------------------------------- >> Dipl.-Inf. Georg Fette Raum: B001 >> Universität Würzburg Tel.: +49-(0)931-31-85516 >> Am Hubland Fax.: +49-(0)931-31-86732 >> 97074 Würzburg mail: georg.fe...@uni-wuerzburg.de >> --------------------------------------------------------------------- >> >> >> _______________________________________________ >> openEHR-implementers mailing list >> openEHR-implementers@lists.openehr.org >> >> http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org >> > > > -- > *Ing. Pablo Pazos Gutiérrez* > pablo.pa...@cabolabs.com > +598 99 043 145 > skype: cabolabs > Subscribe to our newsletter <http://eepurl.com/b_w_tj> > <https://cabolabs.com/> > http://www.cabolabs.com > https://cloudehrserver.com > > _______________________________________________ > openEHR-implementers mailing list > openEHR-implementers@lists.openehr.org > > http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org >
_______________________________________________ openEHR-implementers mailing list openEHR-implementers@lists.openehr.org http://lists.openehr.org/mailman/listinfo/openehr-implementers_lists.openehr.org
