# Aql teaser 4 for implementers

**URL:** <https://discourse.openehr.org/t/aql-teaser-4-for-implementers/401>\
**Category:** AQL\
**Tags:** aql\
**Created:** [3 March 2020 09:37 UTC](https://discourse.openehr.org/t/aql-teaser-4-for-implementers/401 "2020-03-03T09:37:59Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Seref](https://discourse.openehr.org/user_avatar/discourse.openehr.org/seref/32/13_2.png) [@Seref](https://discourse.openehr.org/u/Seref)\
**Post date:** [3 March 2020 09:37 UTC](https://discourse.openehr.org/t/aql-teaser-4-for-implementers/401/1 "2020-03-03T09:37:59Z")

</div>

Dear implementers:  
@bna @matijap @ian.mcnicoll

Given the composition on the left, and the AQL query after that, what should the result set for the select clause on the right be? Same as before: think on it whenever you have some free time

 ![image](https://discourse.openehr.org/uploads/default/original/1X/83fbd5e0a717cd93e0ee9cb4c0afc19267d9efab.png)

```
SELECT
    c,s,i_1,i_2
FROM
    COMPOSITION C c
        CONTAINS
    SECTION s
        CONTAINS 
    (INSTRUCTION i_1 OR INSTRUCTION i_2)

```

\<c|s|i|\> on the leftmost tree is a composition|section|instruction instance, i.e. a single composition instance.

---

<div class="post-metadata">

**Author:** ![matijap](https://discourse.openehr.org/user_avatar/discourse.openehr.org/matijap/32/233_2.png) [@matijap](https://discourse.openehr.org/u/matijap)\
**Post date:** [4 March 2020 08:00 UTC](https://discourse.openehr.org/t/aql-teaser-4-for-implementers/401/2 "2020-03-04T08:00:21Z")

</div>

In my head, the answer is clear: you get two rows, one with i1 in i\_1 and i\_2=null, and one where i\_1=null and i\_2=i1.

That is _not_ what you’d get with SQL outer join and an additional condition that i\_1 != i\_2: you’d get no rows, because there would be no row with any of the variables being null before applying the non-equality condition.

To my horror, that is even _not_ what you get with Better EHR Server: you also get no rows. Which seems wrong to me. I’m sure @bna’s team handles this properly given what he said in teaser #1 (and with what I tend do disagree, but when applied to this case it would probably lead to more logica behaviour).

---

<div class="post-metadata">

**Author:** ![Seref](https://discourse.openehr.org/user_avatar/discourse.openehr.org/seref/32/13_2.png) [@Seref](https://discourse.openehr.org/u/Seref)\
**Post date:** [4 March 2020 09:05 UTC](https://discourse.openehr.org/t/aql-teaser-4-for-implementers/401/3 "2020-03-04T09:05:44Z")

</div>

> [@matijap](#):
>
> In my head, the answer is clear: you get two rows, one with i1 in i\_1 and i\_2=null, and one where i\_1=null and i\_2=i1.

Thank you. That’s exactly what I’d suggest as the correct behaviour.

> [@matijap](#):
>
> That is _not_ what you’d get with SQL outer join and an additional condition that i\_1 != i\_2: you’d get no rows, because there would be no row with any of the variables being null before applying the non-equality condition.

Not only that, but in more complex cases, outer joins would still fail you depending on the results of previous outer joins, if you’re thinking in terms of relational algebra. I won’t go into that here, but let me just say that I use this example to show that CONTAINS semantics with disjunction cannot be represented with relational joins as a first class concept.

> [@matijap](#):
>
> To my horror, that is even _not_ what you get with Better EHR Server: you also get no rows. Which seems wrong to me

Don’t worry, you’re not the only one 😉

> [@matijap](#):
>
> but when applied to this case it would probably lead to more logica behaviour

And this is why I’m laying out different cases, to build an argument towards consistent behaviour of logical operators. The price of consistency is inconvenience but dealing with inconvenience is much,much cheaper in cost compared to cost of inconsistency, especially among vendors.