feat: Rework SQL connection check to application lifecylce#3857
feat: Rework SQL connection check to application lifecylce#3857awildturtok wants to merge 9 commits intodevelopfrom
Conversation
96d9921 to
19b5de0
Compare
backend/src/main/java/com/bakdata/conquery/models/config/DatabaseConnection.java
Outdated
Show resolved
Hide resolved
backend/src/main/java/com/bakdata/conquery/models/config/DatabaseConnection.java
Outdated
Show resolved
Hide resolved
| log.info("SUCCESS connecting to {}", getJdbcConnectionUrl()); | ||
| } | ||
| else { | ||
| log.error("FAILED connecting to {}. Connection did not become valid.", getJdbcConnectionUrl()); |
There was a problem hiding this comment.
Sind in der Url Credentials enthalten?
backend/src/main/java/com/bakdata/conquery/mode/local/LocalNamespaceHandler.java
Outdated
Show resolved
Hide resolved
| initializeDataSource(); | ||
| } | ||
|
|
||
| public void initializeDataSource() { |
There was a problem hiding this comment.
Zum Beispiel so
| public void initializeDataSource() { | |
| public ManagedDataSource initializeDataSource() { |
| * Keys must match the name of existing {@link Dataset}s. | ||
| */ | ||
| private Map<String, @Valid DatabaseConfig> databaseConfigs; | ||
| private Map<DatasetId, @Valid DatabaseConnection> databaseConfigs; |
There was a problem hiding this comment.
Funktioniert die Deserialisierung der Keys einfach so ohne Annotationen?
| public void close() { | ||
| closeDslContextWrapper(); | ||
| //TODO do we even need to shutdown the connection? | ||
| super.close(); | ||
| } |
There was a problem hiding this comment.
Denke schon, wenn man ein Dataset löscht und dann wieder anlegt, sollte sich auch die Connection erneuern.
There was a problem hiding this comment.
Das Ding ist halt, die Connection liegt nicht im Dataset sondern in der config.json
There was a problem hiding this comment.
Deswegen sollte das nicht in der Config gehalten werden, sondern in einem separaten Objekt gemanaged werden. Bei Solr habe ich letztendlich die Dataset bezogenen Connections nicht über den Lifecycle gemanaged, weil sie nur bedingt an diesen gebunden sind.
There was a problem hiding this comment.
Der Zweck des PRs ist ja aber die Connection an den Lifecylce zu binden und eben nicht mehr an das Dataset. Damit es dann auch beim hochfahren direkt gefangen wird etc. Ich räum es aber auf jeden Fall auf
There was a problem hiding this comment.
Das hat sich dann jetzt erledigt, oder die Connection wird nicht mehr hier gemanaged
| getDialect().getJooqDialect(), | ||
| settings | ||
| ); | ||
| } |
There was a problem hiding this comment.
Bitte diese Methode auch in eine ManagedDatasource packen
| // TODO this could be implemented as a plugin tbh | ||
| if(config.getSqlConnectorConfig() != null) { | ||
| config.getSqlConnectorConfig().initialize(environment); | ||
| } |
There was a problem hiding this comment.
Oder ein ConfiguredBundle, da kannst du checken ob SqlConnectorConfig gesetzt/enabled ist, Resources/Services registrieren für Injection, Healthchecks setzten...
1c0f11d to
054aef3
Compare
thoniTUB
left a comment
There was a problem hiding this comment.
Ich bin mir nicht ganz sicher hat das mit der Clock etwas mit dem Lifecycle zu tun oder kannst du das trennen?
| public void close() { | ||
| closeDslContextWrapper(); | ||
| //TODO do we even need to shutdown the connection? | ||
| super.close(); | ||
| } |
There was a problem hiding this comment.
Das hat sich dann jetzt erledigt, oder die Connection wird nicht mehr hier gemanaged
backend/src/main/java/com/bakdata/conquery/sql/conversion/cqelement/ConversionContext.java
Show resolved
Hide resolved
|
|
||
| // join full stratification with connector table on all ID's from prerequisite query | ||
| SqlFunctionProvider functionProvider = tableContext.getConversionContext().getSqlDialect().getFunctionProvider(); | ||
| SqlFunctionProvider functionProvider = tableContext.getConversionContext().getDialectBundle().getFunctionProvider(); |
There was a problem hiding this comment.
hey().du().hast().mir().mal().vom().LoD().erzählt() :D
| @SneakyThrows | ||
| public static void waitUntil(Supplier<Boolean> condition) { | ||
| Stopwatch stopwatch = Stopwatch.createStarted(); | ||
| int done = 0; | ||
|
|
||
| while (stopwatch.elapsed(TimeUnit.SECONDS) < 10) { | ||
| Thread.sleep(2); | ||
| if (!condition.get()) { | ||
| continue; | ||
| } | ||
|
|
||
| //sample multiple times from the job queues to make sure we are done with everything and don't miss late arrivals | ||
| done++; | ||
| if (done > 5) { | ||
| return; | ||
| } | ||
| } | ||
|
|
||
| throw new IllegalStateException("Jobs did not finish within expected time."); | ||
| } | ||
|
|
There was a problem hiding this comment.
Ich weiß die ist nur verschoben, aber kann ggf mit https://github.com/awaitility/awaitility abgebildet werden. Das sollte auch schon in der pom sein
Der Grund, dass das hier mit reingerutscht ist, ist dass ich die Komponenten die davor den DateNowSupplier gehalten habe aufgetrennt habe und den dann von wo anders mitbringen musste. |
| public interface DialectBundle { | ||
|
|
||
| SystemDateNowSupplier SYSTEM_DATE_NOW_SUPPLIER = new SystemDateNowSupplier(); | ||
| //TODO add getDateNow and access it directly |
| import org.jooq.Field; | ||
|
|
||
| public interface SqlDialect { | ||
| //TODO unify with com.bakdata.conquery.models.config.Dialect |
No description provided.