Add SQL conversion of conditions #3252
Conversation
Das hast du richtig verstanden, die conditions werden verundet. |
| Field<String> field = DSL.field(DSL.name(context.getConnectorTable().getName(), context.getConnectorColumn().getName()), String.class); | ||
| LikeEscapeStep condition = Arrays.stream(prefixes) | ||
| .map(prefix -> field.like(prefix + "%")) | ||
| .reduce((like1, like2) -> (LikeEscapeStep) like1.or(like2)) |
There was a problem hiding this comment.
Gibt es keine bessere Möglichkeit das zu lösen? Hier wird das für psql skizziert: https://dba.stackexchange.com/questions/236627/how-to-use-like-operator-with-multiple-conditions-at-once-in-postgresql
Das sieht besser aus, einfach weil es echt große Listen werden können. Aber natürlich fragwürdig wie das über unterschiedliche DBs hinweg funktioniert.
There was a problem hiding this comment.
Sehe weiter unten likeRegex, vlt im regex die Veroderung machen und benchmarken? Das können nämlich locker 100 Werte sein
| @@ -40,4 +48,28 @@ public boolean matches(String value, CalculatedValue<Map<String, Object>> rowMap | |||
| return false; | |||
| } | |||
|
|
|||
| @Override | |||
| public WhereCondition convertToSqlCondition(CTConditionContext context) { | |||
| @@ -47,13 +52,13 @@ public Class<CQConcept> getConversionClass() { | |||
| } | |||
|
|
|||
| @Override | |||
| public ConversionContext convert(CQConcept node, ConversionContext context) { | |||
| public ConversionContext convert(CQConcept cqConcept, ConversionContext context) { | |||
There was a problem hiding this comment.
warum ist der CQConceptConverter (noch) nicht in CQConcept inlined?
There was a problem hiding this comment.
Wir hatten uns erstmal (noch) dagegen entschieden, weil dann relativ viel Code im CQConverter liegt. Aber da können wir ja auch nochmal drüber sprechen, ob wir auch die verbleibenden Converter mit in die jeweiligen Klassen ziehen wollen. @torbsto
| public WhereClauses negated() { | ||
| return new WhereClauses( | ||
| preprocessingConditions.stream().map(WhereCondition::negate).toList(), | ||
| eventFilters.stream().map(WhereCondition::negate).toList(), |
There was a problem hiding this comment.
da hab ich mir schon länger gedanken zu gemacht und immer noch keine Eindeutige Antwort gefunden, aber ich glaube event-filters werden nicht negated, das macht sonst aggregationen etwas weird.
| "description": " ", | ||
| "condition": { | ||
| "type": "OR", | ||
| "conditions": [ |
There was a problem hiding this comment.
Durschnschnittliche Condition 🧛
There was a problem hiding this comment.
😄 Ich benenne den Fall mal um.
| { | ||
| "label": "F22.8", | ||
| "description": "Sonstige anhaltende wahnhafte Störungen", | ||
| "additionalInfos": [ |
There was a problem hiding this comment.
kannst du die additionalInfos und die descriptions bitte entfernen?
|
@awildturtok Habe das mit dem Regex mal getestet, deine Vermutung war wohl zutreffend 😄 TL;DRcost of 86316.64 (with Regex) < cost of 270699.83 (with LIKE 'foo' OR LIKE 'bar' etc.) I used this dataset: https://postgrespro.com/docs/postgrespro/10/demodb-bookings-installation (demo-big, about 2,5 GB data), with 2.9 million With LIKE 'foo' OR LIKE 'bar' etc.EXPLAIN ANALYSE select *
from "tickets"
where "passenger_name" LIKE 'A%'
or "passenger_name" LIKE 'B%'
or "passenger_name" LIKE 'C%'
or "passenger_name" LIKE 'D%'
or "passenger_name" LIKE 'E%'
or "passenger_name" LIKE 'F%'
or "passenger_name" LIKE 'G%'
or "passenger_name" LIKE 'H%'
or "passenger_name" LIKE 'I%'
or "passenger_name" LIKE 'J%'
or "passenger_name" LIKE 'K%'
or "passenger_name" LIKE 'L%'
or "passenger_name" LIKE 'M%'
or "passenger_name" LIKE 'N%'
or "passenger_name" LIKE 'O%'
or "passenger_name" LIKE 'P%'
or "passenger_name" LIKE 'Q%'
or "passenger_name" LIKE 'R%'
or "passenger_name" LIKE 'S%'
or "passenger_name" LIKE 'T%'
or "passenger_name" LIKE 'U%'
or "passenger_name" LIKE 'V%'
or "passenger_name" LIKE 'W%'
or "passenger_name" LIKE 'X%'
or "passenger_name" LIKE 'Y%'
or "passenger_name" LIKE 'Z%'Cost: (cost=0.00..270699.83 rows=1919327 width=104) With RegexEXPLAIN ANALYSE SELECT *
FROM "tickets"
WHERE "passenger_name" SIMILAR TO '[A-Z]%';
# or more realistic
SELECT *
FROM "tickets"
WHERE "passenger_name" SIMILAR TO '(A|B|C|D|E|F|G|H|I|J|K|L|M|N|O|P|Q|R|S|T|U|V|W|X|Y|Z)%';Cost: (cost=0.00..86316.64 rows=2949862 width=104) |
First commit contains only renaming
Filters->WhereClausesandFilterCondition->WhereCondition.Second commit contains the conversion of all CTConditions except for the
GroovyCondition.CTConditionsare applied inPREPROCESSINGCTE step.CTConditions, but if theCTConditionhas a column itself, the given connector column is ignored.(An der Stelle ist mir eingefallen, dass wir ja hier auf deutsch schreiben, deswegen hier der Wechsel 😄 )
Bei einer Sache war ich mir noch unsicher: aktuell gucke ich im
CQConceptnach denConceptElementsund im Falle vonConceptTreeChildskonvertiere ich die entsprechendeCTCondition. Zusätzlich konvertiere ich auch IMMER dieCTConditiondesConnectors(falls vorhanden). Passt das so oder wird dieConditionvomConnectornur angewandt, wenn das top-levelTreeConceptausgewählt ist?