deployment problems - Initialization failed for Singleton StartupFlywayMigrator
Jacek Chudzik
James Myers
Jacek,
You shouldn’t see this with the official releases. If you did, please submit a bug. The underlying error is related to how Dataverse applies sql update scripts using Flyway. Two scripts with the same number will conflict. https://guides.dataverse.org/en/latest/developers/sql-upgrade-scripts.html?highlight=flyway has details and the last section there describes how to resolve your problem.
- Jim
--
You received this message because you are subscribed to the Google Groups "Dataverse Users Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
dataverse-commu...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/dataverse-community/7e9381d4-ca19-4b02-96d0-bcc5e794380bn%40googlegroups.com.
Jacek Chudzik
James Myers
Hmm – if the file is there, all I can think of would be a permissions issue, but why that would apply to only one file, I don’t know.
One thing to clarify w.r.t. the debugging instructions: you should not truncate the table, just delete the row(s) for the recent/conflicting files. In general, the scripts have been idempotent – able to be rerun on the same database without issue, but I think some were not (although I don’t have a specific example.)
-- Jim
To view this discussion on the web visit https://groups.google.com/d/msgid/dataverse-community/aba81da4-69eb-4889-8366-75340ae6f060n%40googlegroups.com.
Jacek Chudzik
James Myers
Jacek,
I don’t have good suggestions for you as I don’t understand why your install is failing. The Flyway scripts are in the war file and you should see them inside the exploded war file at the relative path ./WEB-INF/classes/db/migration. In my local install I see a 111 byte V4.13.0.1__3575-usernames.sql there along with all the other scripts.
For you to get an “Unable to find resource on disk: db/migration/V4.13.0.1__3575-usernames.sql” error, I can only guess that the file isn’t at the path above or that the permissions for the operating system user account running payara/dataverse don’t allow it to read that file. If that’s not it, I don’t know what else could cause this specific issue.
The one known scenario where we see flyway issues is where a developer has been installing multiple branches. If I’ve been working on code that would require a V5.14.0.1-my-work.sql file and I then I work on another branch where another developer has created V5.14.0.1-their-work.sql, when I try to install flyway will fail because the V5.14.0.1 script has changed. Deleting that last row from the flyway table allows it to install V5.14.0.1-their-work.sql correctly and I can then create a V5.14.0.2 file to keep developing.
With the releases, we make sure such changes don’t occur so there should never be cases where you get a flyway error going from v12.1 to v13.
With a truncated table, I could imagine you could now get other errors (if reapplying one of the scripts gives an error because it isn’t idempotent), so I would definitely check to make sure you’re still stuck with the “Unable to find resource on disk” error and not something new. If you get something new, I’d suggest either restoring from a backup database or replacing the flyway table from a backup or another successful v12.1 install (**this is only an option if/when you are sure that all of the listed flyway scripts were actually applied to your postgres db in the past. If they were not, you will have a db missing changes/constraints**).
Another thought – since Flyway is a standard component, you may be able to find something else on the web about how/when those Unable to find resource on disk errors can occur.
I hope some of that helps,
--Jim
To view this discussion on the web visit https://groups.google.com/d/msgid/dataverse-community/81d9c3a5-151f-4e0f-9109-d57ca6a9c3f1n%40googlegroups.com.