ptrdom opened a new issue, #158: URL: https://github.com/apache/pekko-persistence-r2dbc/issues/158
Since MySQL is still one of the most popular RDMS, it makes a lot of sense to add support for it, hopefully helping with adoption of Pekko Persistence R2DBC. Looking through the existing Postgres implementation for potential challenges with MySQL support, it seems to me that the main difference between the databases is that MySQL does not have concept of a `transaction_timestamp`. There are ways to implement it - for example wrapping a write operation in a procedure that has a local variable with a timestamp that gets reused in a transaction that is started, but I am not sure if there is much benefit in trying to implement database-side timestamps - I do not understand why it should be a dealbreaker for a production-ready implementation, because no matter where you get your timestamps from, whether it is the application or the database, you will still be dealing with potential clock skews, just that the risk levels might be different, dependent on the architecture of a particular deployment. So my thinking is that we could implement MySQL support by requiring the use of `use-app-timestamp = on` and possibly `db-timestamp-monotonic-incr easing = off`. Could there be any issues with this approach? Are there any more issues with the implementation or can we just proceed with it? -- 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: notifications-unsubscr...@pekko.apache.org.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: notifications-unsubscr...@pekko.apache.org For additional commands, e-mail: notifications-h...@pekko.apache.org
