ptrdom commented on issue #158: URL: https://github.com/apache/pekko-persistence-r2dbc/issues/158#issuecomment-2433063857
Trying to figure out how to best hook up per database implementations with multiple sbt module approach. Since the only existing implementation has not created abstractions for this, we need to come up with a solution. The way to do similar things to what we need in Pekko ecosystem repositories seems to be by specifying class name in config and constructing an instance of it by the use of reflection. To make this work I think that instead of this: https://github.com/apache/pekko-persistence-r2dbc/blob/7dd8b64361fe926aa1143362148a6e2ba01ca137/core/src/main/resources/reference.conf#L105 We need to do something like `dialect.class`, which would allow providing different implementations of `JournalDao`: https://github.com/apache/pekko-persistence-r2dbc/blob/7dd8b64361fe926aa1143362148a6e2ba01ca137/core/src/main/scala/org/apache/pekko/persistence/r2dbc/journal/JournalDao.scala#L82 `R2dbcJournal` would then load the specified implementation. We would also convert current `JournalDao` to a trait and add a Postgres/Yugabyte implementation for it. We could also start with splitting Postgres/Yugabyte implementation to its own module and get the abstractions right before proceeding with MySQL support. Good idea with this work would be to also make test suites as traits that are implemented by each database implementation separately. @pjfanning Any thoughts? I am up to do any solution for this and do not have any strong opinions. -- 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]
