search

akka / akka-persistence-jdbc

Asynchronously writes journal and snapshot entries to configured JDBC databases so that Akka Actors can recover state
https://doc.akka.io/docs/akka-persistence-jdbc/
Other
308 stars 142 forks source link

migrate SQL Server Schemas to NVARCHAR #652

Closed leviramsey closed 1 year ago

leviramsey commented 2 years ago

References #650

leviramsey commented 2 years ago

Re: docs, I'm not sure where a "if using a journal/snapshot store created with Akka Persistence versions 5.0.4 and earlier, it is advised to disable the JDBC client's sending strings as unicode" note should go.

leviramsey commented 2 years ago

Thoughts on restructuring the docs along the lines of the Cassandra plugin with notes for the different DBs?

octonato commented 2 years ago

About the docs, I think we should add it to the migration guide.

Now it's a good moment to do it. We have another PR, less critical, that will also require a migration guide.

And we didn't documented the migration tool that was added in #603.

Maybe we should go for 5.1.0 because of the DB changes.

leviramsey commented 2 years ago

We should document a recommendation if using the old (VARCHAR-based) SQL Server schemas (regardless of APJDBC version) to use the ;sendStringParametersAsUnicode=false connection parameter.

To my knowledge it's not a simple migration from the old schema to the new schema, and as far as Slick is concerned it's the same schema (in that the JVM types each column maps to are unchanged).

leviramsey commented 2 years ago

Actually I guess we can support offline migration of data from an old journal/snapshot-store to a new journal/snapshot-store, but I think it would be generally preferable from the user perspective to use the old schema and configure JDBC to work properly with the old schema.

That said, the migration tool would support the "turns out, we need unicode persistence IDs or tags" use case.

patriknw commented 1 year ago

@leviramsey would it be possible to push this forward?

leviramsey commented 1 year ago

I guess the question is if we want to implement a migration tool (which honestly is not something I'm confident on being able to implement any time soon).

As it is, this should just be mergeable (it requires no code changes, AFAIK), perhaps with docs around ;sendStringParametersAsUnicode=false for use with previous versions of the schema.