Conversation
# Conflicts: # backend/src/main/java/com/bakdata/conquery/mode/local/LocalStorageListener.java
… SqlMatchingStats easier
Also fixes a case, where missing entries were not registered to the root.
…tats-as-sql-function # Conflicts: # backend/src/main/java/com/bakdata/conquery/models/messages/namespaces/specific/UpdateMatchingStatsMessage.java
(experimental)
(this is a bit absurd tbh)
| @Data | ||
| public abstract class StorageListener<T extends Namespace>{ |
There was a problem hiding this comment.
Ich hätte das Interface beibehalten und davon diese abstract Class abgeleitet.
Interfaces können auch praktisch sein, da man für diese Proxies implementieren kann
There was a problem hiding this comment.
Ich hatte glaube ich gehofft mehr logik zu vereinheitlichen, bin auch nicht deiner Meinung. Aber hier ist es definitiv die klasse wert.
81dd8ff to
4366d85
Compare
db2209e to
1ef85b9
Compare
4a218ad to
14b72b5
Compare
…tats-as-join-table # Conflicts: # backend/src/main/java/com/bakdata/conquery/mode/local/LocalManagerProvider.java # backend/src/main/java/com/bakdata/conquery/models/worker/LocalNamespace.java # backend/src/main/java/com/bakdata/conquery/sql/conversion/cqelement/concept/CQConceptConverter.java # backend/src/main/java/com/bakdata/conquery/sql/conversion/dialect/PostgreDialectBundle.java # backend/src/main/java/com/bakdata/conquery/sql/conversion/query/TableExportQueryConverter.java # backend/src/main/java/com/bakdata/conquery/util/TablePrimaryColumnUtil.java # backend/src/test/java/com/bakdata/conquery/integration/json/SqlTestDataImporter.java
89dca10 to
8afe6c0
Compare
8afe6c0 to
9871265
Compare
|
|
||
|
|
||
| @Override | ||
| public void execute() throws Exception { |
There was a problem hiding this comment.
Hier bin ich noch ziemlich unentschlossen ob das reicht. Ich denke ich möchte auf jeden Fall die HikariConfig exposen in der config.json. Dann können wir darüber das connection management machen anstatt Angst zu haben
|
|
||
| Stopwatch stopwatch = Stopwatch.createStarted(); | ||
|
|
||
| ExecutorService executorService = Executors.newSingleThreadExecutor(); |
There was a problem hiding this comment.
die collectMatchingStatsForConcept hat ein async callable, das sollte also genau passen
| @Data | ||
| public abstract class StorageListener<T extends Namespace>{ |
There was a problem hiding this comment.
Ich hatte glaube ich gehofft mehr logik zu vereinheitlichen, bin auch nicht deiner Meinung. Aber hier ist es definitiv die klasse wert.
|
|
||
| boolean matches(String value, CalculatedValue<Map<String, Object>> rowMap) throws ConceptConfigurationException; | ||
|
|
||
| //TODO implement using join-table |
There was a problem hiding this comment.
ist ein separates Projekt, also kann bleiben
| protected static Field<Object> coalesceFields(List<Field<?>> fields) { | ||
| if (fields.size() == 1) { | ||
| return fields.get(0).coerce(Object.class); | ||
| protected static <T> Field<T> coalesceFields(List<? extends Field<?>> fields, Class<T> type) { |
There was a problem hiding this comment.
weiß leider nicht mehr wo aber hier gab es einen komischen Bug damit.
There was a problem hiding this comment.
Ist es schlau hier die Argumente (also fields.get(0)) zu überschreiben? Willst du die Funktion nicht lieber idempotent machen.
Ich würde auch das coerce erst im Nachgang machen, wenn das geht.
There was a problem hiding this comment.
das sieht tatsächlich besser aus, danke
thoniTUB
left a comment
There was a problem hiding this comment.
Ich muss nochmal weiter machen.
|
|
||
| @Setter @Getter @NotEmpty | ||
| private Set<String> values; | ||
| @NotEmpty @Setter @Getter |
There was a problem hiding this comment.
| @NotBlank @Setter @Getter |
| public class ColumnEqualCondition implements CTCondition { | ||
|
|
||
| @Setter @Getter @NotEmpty | ||
| private Set<String> values; |
There was a problem hiding this comment.
| private Set<@NotBlank String> values; |
| fieldParams = otherParams; | ||
| } | ||
| else { | ||
| fieldParams = Sets.intersection(otherParams, myParams); |
There was a problem hiding this comment.
Warum ist das ein intersect und kein union?
There was a problem hiding this comment.
weil die zwei elemente verwundet werden
There was a problem hiding this comment.
🩸 🗡️
Okay muss ich nochmal überdenken, ich dachte hier werden Filter/Conditionen verundet und nicht die gefilterten Werte
There was a problem hiding this comment.
hier werden Concept-Conditions verundet
| //TODO better name | ||
| record Expression(ConceptElement<?> conceptElement, Map<Field<?>, Set<Param<?>>> conditions) { |
There was a problem hiding this comment.
Es wird ja nur für matching stats genommen, oder? Dann würde ich das in den Namen einfließen lassen
| /** | ||
| * This condition requires that the selected Column has a value. | ||
| */ | ||
| @CPSType(id="PRESENT", base=CTCondition.class) |
| /** | ||
| * Drop the table, then recreate it. | ||
| */ | ||
| private void createConceptIdsTable(Name tableName, List<Field<?>> fields) { | ||
|
|
||
| log.debug("Creating table {} with fields {}", tableName, fields); | ||
|
|
||
| CreateTableElementListStep createTable = | ||
| dslContext.createTable(tableName) | ||
| .columns(fields); | ||
|
|
||
| log.info("{}", createTable); |
There was a problem hiding this comment.
Ist das drop implizit? ich sehe es hier nicht
There was a problem hiding this comment.
passiert im caller
There was a problem hiding this comment.
Dann bitte die Doku anpassen
| protected static Field<Object> coalesceFields(List<Field<?>> fields) { | ||
| if (fields.size() == 1) { | ||
| return fields.get(0).coerce(Object.class); | ||
| protected static <T> Field<T> coalesceFields(List<? extends Field<?>> fields, Class<T> type) { |
There was a problem hiding this comment.
Ist es schlau hier die Argumente (also fields.get(0)) zu überschreiben? Willst du die Funktion nicht lieber idempotent machen.
Ich würde auch das coerce erst im Nachgang machen, wenn das geht.
| { | ||
| "type": "QUERY_TEST", | ||
| "sqlSpec": { | ||
| "isEnabled": true |
| case MONEY -> true; // Not possible to introspect for | ||
| case DATE -> field.getDataType().isDate(); | ||
| case DATE_RANGE -> field.getDataType().getTypeName().equals("daterange"); | ||
| case DATE_RANGE -> true; // Not possible to introspect for |
There was a problem hiding this comment.
We wäre es hiermit?
| case DATE_RANGE -> true; // Not possible to introspect for | |
| case DATE_RANGE -> field.getDataType().getType().equals(org.jooq.postgres.extensions.types.DateRange.class); |
There was a problem hiding this comment.
ich kann mal schauen, aber iirc kommen die einfach als Object zurück
There was a problem hiding this comment.
Zu mindest in den Tests würde habe ich gesehen, dass hier passen würde
There was a problem hiding this comment.
Ich meine, dass ich es in den Tests auch mal drin hatte und dann deaktivieren musste, sobald ich es auf eine separate Instanz hab zeigen lassen. Ich habs mal zurückgedreht und schau es mir an.
Eine Beispielhafte join-table könnte folgende Einträge enthalten:
im Falle von ColumnEquals wären dann noch weitere Spalten dabei. Bei PRESENT/EMPTY wären stattdessen true/false drin, die dann im join abgebildet werden.