Rework select and filter conversion #3453
Conversation
|
Die Intention hierfür war ja dass, Daterange Columns Dialect abhängig genutzt werden können oder? #3446 |
|
@thoniTUB Ich hatte den Ansatz nochmal überdacht: die Möglichkeit, die Daterange Columns zu nutzen ist über bereits existierende Funktionalität aus den Die Intention für diesen PR war eher, das die Abstraktionen |
|
@awildturtok FYI: ich habe die beiden * |
backend/src/main/java/com/bakdata/conquery/sql/conversion/cqelement/concept/TablePath.java
Outdated
Show resolved
Hide resolved
backend/src/main/java/com/bakdata/conquery/sql/conversion/cqelement/concept/TablePath.java
Outdated
Show resolved
Hide resolved
backend/src/main/java/com/bakdata/conquery/sql/conversion/cqelement/concept/TablePath.java
Show resolved
Hide resolved
.../main/java/com/bakdata/conquery/sql/conversion/model/aggregator/CommonAggregationSelect.java
Outdated
Show resolved
Hide resolved
| public class BigMultiSelectFilterConverter extends AbstractSelectFilterConverter<BigMultiSelectFilter, String[]> { | ||
|
|
||
| @Override | ||
| protected String[] getValues(FilterContext<String[]> filterContext) { |
There was a problem hiding this comment.
die abstraktion musst du gar nicht machen, Big/-Multi sind fürs FE relevant und ein bisschen, wie wir sie aufbereiten dafür im Backend. Logik ist die gleiche
There was a problem hiding this comment.
Was meinst du mit "muss ich nicht machen?" Heißt das im Backend kommt immer nur ein SelectFilter und für Big/Multi brauch ich keinen Converter?
There was a problem hiding this comment.
@awildturtok Nur nochmal ein Ping für ☝️
There was a problem hiding this comment.
sry habe das nicht in meinen PRs gesehen. du kannst für beide den gleichen converter verwenden.
Kurze warunung, ich habe vor die FilterValue von BigMult und Multi auf Set zu migrieren. Das nicht zu machen hat bei uns zu performance problemen geführt.
…and-filter-conversion # Conflicts: # backend/src/main/java/com/bakdata/conquery/models/datasets/concepts/select/Select.java # backend/src/main/java/com/bakdata/conquery/models/datasets/concepts/select/concept/specific/EventDateUnionSelect.java # backend/src/main/java/com/bakdata/conquery/models/datasets/concepts/select/concept/specific/EventDurationSumSelect.java # backend/src/main/java/com/bakdata/conquery/models/datasets/concepts/select/concept/specific/ExistsSelect.java # backend/src/main/java/com/bakdata/conquery/models/datasets/concepts/select/connector/specific/CountQuartersSelect.java # backend/src/main/java/com/bakdata/conquery/models/datasets/concepts/select/connector/specific/CountSelect.java # backend/src/main/java/com/bakdata/conquery/models/datasets/concepts/select/connector/specific/DateDistanceSelect.java # backend/src/main/java/com/bakdata/conquery/models/datasets/concepts/select/connector/specific/FlagSelect.java # backend/src/main/java/com/bakdata/conquery/models/datasets/concepts/select/connector/specific/SumSelect.java
This is "just" a refactoring PR, it did not introduce new features.
Some relevant changes made:
SelectConverterandFilterConverterclass -SqlAggregatorsare now just a marker interface to bundle aSelectConverterandFilterConverterif their is aSelectandFilterof the same kind (CountSelect,CountFilter,SumSelect,SumFilter, etc.). ForSelectswhich have no correspondingFilter(First,Last, etc.), there exists only aSelectConverter. ForFilterswhich have no correspondingSelect(NumberFilter,SelectFilter, etc.), there exists only aFilterConverter.SelectConvertershave 2 methods for converting aSelectonConcept-level and onConnector-Level.FilterConvertershave 2 methods for converting aFilterforConcept-conversion and for table export.Holderclass for select and filter converters to connect a concreteSelect/Filterwith their respective converter. This makes casts/more generics onSelectsandFiltersomitable.SqlSelectswithConnectorSqlSelects/ConceptSqlSelects.TablePathGenerator->TablePathand changed the behavior a little bit.The majority of all the other changes were just moving existing code around.