tchughesiv commented on PR #372: URL: https://github.com/apache/incubator-kie-kogito-serverless-operator/pull/372#issuecomment-1946209500
> > > In this other use case below, we are using a SFP with the global persistence configured to use the JdbcUrl to connect with the database service. > > > https://github.com/flows-examples/techpreview2/tree/004b37b96ad5f75c804d8e8ba3d821ab67c86457/platforms/openshift-dataindex_and_jobservice_as_platform_service_and_global_persistence_jdbcurl_postgresql > > > ``` > > > > > > persistence: > > > > > > postgresql: > > > > > > secretRef: > > > > > > name: postgres-secrets > > > > > > userKey: POSTGRESQL_USER > > > > > > passwordKey: POSTGRESQL_PASSWORD > > > > > > jdbcUrl: jdbc:postgresql://postgres.usecase3-platform-persistence-jdbcurl-oc:5432/sonataflow2 > > > ``` > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > But, the corresponding generated specific jdbc url for each service looks like the ones below. > > > I think we need a small adjustment to make each service use its specific schema, otherwise we have flyway issues when the services start. Not too much, a simple adjustment. > > > **DataIndex:** > > > ``` > > > QUARKUS_DATASOURCE_JDBC_URL = jdbc:postgresql://postgres.usecase3-platform-persistence-jdbcurl-oc:5432/sonataflow2 > > > ``` > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > **JobsService:** > > > ``` > > > QUARKUS_DATASOURCE_JDBC_URL = jdbc:postgresql://postgres.usecase3-platform-persistence-jdbcurl-oc:5432/sonataflow2 > > > ``` > > > > > > That's because when I posted about the schema being included in the JbdcUrl in slack, it was suggested we should not do anything to remove the schema from it and instead warn the user in the documentation that it can cause problems when defined in the platform. > > ok, looks like I missed these comments. Maybe, if JdbcUrl is something that people can't use at platform level, we can throw an error in that case 🤔 is it a 100% certainty that `JdbcUrl` can't be used in any capacity at the `platform.spec` level? if so, then yes... we either need to remove it from the `PlatformPersistenceOptionsSpec` (this is preferable... like we already did for databaseSchema) OR document it i guess. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
