Add support for LIKE on AQL syntax
Description
PR is addressed in
Activity
Pablo Pazos February 25, 2020 at 9:37 PM
+1 on using LIKE only for primitive Strings
Thomas Beale February 18, 2020 at 11:31 AM
I agree with others - let's stick to LIKE for primitive Strings for now. Anything else I think is hard to understand and query authors are never going to know what queries with LIKE <some DV_TEXT> really mean...
Matija Polajnar February 18, 2020 at 6:27 AM
I agree with @Sebastian Iancu: only on "primitive" values that get treated as strings for purposes of LIKE.
Sebastian Iancu February 14, 2020 at 7:00 AM
To avoid any misconceptions or implementation particularities, I would keep LIKE only on attributes of DV types or others, so only on primitive types like String, etc
Pablo Pazos February 14, 2020 at 5:03 AM
We need to establish to which types this LIKE operator can be applied. For instance, if it should only be applied to the assumed type String, or if it could be applied to openEHR DVs and the AQL processor is the one that internally knows to which single attribute apply the operator. I guess the only difference of these two options is the DV option would have a shorter path, while the String option should have a path to a single String attribute.
/a/b/value/value <String> LIKE “%…”
vs.
/a/b/value <DV_TEXT> LIKE “%…”
Another option would be to allow both.
Some DVs that contain Strings, so LIKE could be applied:
+ DV_TEXT
+ DV_CODED_TEXT
+ DV_DATE, DV_TIME, DV_DATE_TIME
+ DV_ORDINAL
+ DV_IDENTIFIER
+ DV_STATE 
Details
Details
Reporter
Components
Affects versions
Priority
Major
There is a support requested for “LIKE”-like operator for partial text matching. This should support conditions like:
WHERE path/value LIKE "some%"`
See https://www.techonthenet.com/sql/like.php for the level of support of LIKE operator in various SQL implementation.