patsta32 commented on issue #275: URL: https://github.com/apache/pekko-persistence-jdbc/issues/275#issuecomment-2740776000
@pjfanning Hey, i am sorry and i think there is a miscommunication on my side, thanks for your patience with the PR. So i like your idea to make things clear first. I am currently setting up a production project where i have to use a different schema for the persistence plugin in a PostgresDB so i noticed this bug. I would have to contribute to this project or create a fork and build the bug free version myself. ## What is the/my goal As its my only use case currently, fixing the bug for postgres which lead to errors if the durable state is used with a schema name (which is not "public") set in the application.conf file. ### A schema name is and should be not required at any point if the plugin is used, it is and should be optional. --- To just fix the bugs, there are only three changes needed which are already present in my PR: 1. adding the ```def schemaAndTable``` method to DurableStateTableConfiguration in [PekkoPersistenceConfig.scala](https://github.com/apache/pekko-persistence-jdbc/blob/488d78a4f99e75633432658772c188a2c96681bd/core/src/main/scala/org/apache/pekko/persistence/jdbc/config/PekkoPersistenceConfig.scala), so when needed the schema and table name combination can be used through the config. 2. updating ```def insertDbWithDurableState``` and ```def updateDbWithDurableState```in [DurableStateQueries.scala](https://github.com/apache/pekko-persistence-jdbc/blob/488d78a4f99e75633432658772c188a2c96681bd/core/src/main/scala/org/apache/pekko/persistence/jdbc/state/DurableStateQueries.scala) to use the ```schemaAndTable``` method in the sqlu statements. 3. updating ```def getSequenceNextValueExpr``` in [SequenceNextValUpdater.scala](https://github.com/apache/pekko-persistence-jdbc/blob/488d78a4f99e75633432658772c188a2c96681bd/core/src/main/scala/org/apache/pekko/persistence/jdbc/state/SequenceNextValUpdater.scala) to also use the ```schemaAndTable``` method in the sqlu statement. With this changes, the tests will succeed without problems and there are no changes needed for the default configurations. A user who would like to use the reference.conf, postgres-create-schema.sql and postgres-drop-schema.sql could without any problems. Like you mentioned above: > The main thing if you view the scripts in that way is that we should ensure that prod users who do choose to require a schema and who don't want to make that schema the default for their db user account - that they can set the schema name in the conf file and that that works. --- #### Why the other files and script changes: To test if the plugin would be fully functional with schema set for jdbc-journal, jdbc-snapshot-store and jdbc-durable-state-store in the .conf file, the creation or the movement of all tables would be necessary in/to a different schema (which i named "pekko") for testing purposes. I was also testing the plugin without a schema set in configuration and the default files. This setup was present in the first version of my PR. Thats why i created new files and the SchemaType, so both versions (schema set and schema not configure / public) would be tested. With the current state of the PR it is possible to copy the postgres-create-schema.sql and reference.conf files to use them as a starting point for a production setup. There is no need to set the schema in the configuration or the sql files, this is just a option, with the bug resolved. -- 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 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
