Errors like this are normal on mvn docker:run, right?
ERROR: relation "externaltooltype" already exists
STATEMENT: CREATE TABLE EXTERNALTOOLTYPE (ID SERIAL NOT NULL, TYPE VARCHAR(255) NOT NULL, EXTERNALTOOL_ID BIGINT NOT NULL, PRIMARY KEY (ID))
ERROR: relation "index_externaltooltype_externaltool_id" already exists
STATEMENT: CREATE INDEX INDEX_EXTERNALTOOLTYPE_externaltool_id ON EXTERNALTOOLTYPE (externaltool_id)
Screenshot-2024-01-24-at-10.02.58-AM.png
Here's me trying to reassure @Leonhard Maylein in 2015 that similar errors are normal: https://groups.google.com/g/dataverse-community/c/-ITgVIkxdEY/m/oW1tIVe9CQAJ
'That is to say, those exceptions are expected. I believe the "CREATE INDEX" and "INSERT INTO SEQUENCE" exceptions are normal as well. I know they scary, but I think they all have to do with the fact that we let Glassfish create database tables when the war file is deployed. I'm not sure how we would avoid this.' (but Payara instead of Glassfish these days)
As discussed in the container meeting just now, this is unfortunately normal. I'll move this topic out of #containers since it isn't specific to them.
I'm just mentioning create-tables so I can find this topic again. We just talked about it again in the container meeting: https://docs.google.com/document/d/1yiuwS9Ig4qXnQeN1utPt75MUko6M_wRLHIfrCWQM_ZQ/edit?usp=sharing
This topic was mentioned during the CT WG call today again. There might be an easier fix than we expected to create that baseline before we shut down the "create-tables" JPA setting: https://documentation.red-gate.com/fd/baseline-migrations-184127465.html
Huh... baseline migrations. Yes, this sounds like what we need. Thanks!
@Juan Pablo Tosca Villanueva check this out ^^
"Over the lifetime of a project, many database objects may be created and destroyed across many migrations which leaves behind a lengthy history of migrations that need to be applied in order to bring a new environment up to speed.
Instead, you might wish to add a single, cumulative migration that represents the state of your database after all of those migrations have been applied without disrupting existing environments.
Flyway gives you a way to achieve this using Baseline Migrations."
JIm thinks this is a Teams/Enterprise feature...
I'd say we should create a little test project and try if we can apply such migrations if we figure out how to create them
There might be a chance that the creation is simplified by using a Teams license
Sure, sounds like a good experiment. Bummer if it's truly a proprietary feature. I love open source.
But maybe the community version can still apply them... These migrations only apply to new deployments anyway, so it is just a matter of if the community edition will pick up the latest Bx_.sql script
If all of that does not help: for our use case it might be fine to use the "beforeMigrate" callback!
All we want is create the tables etc. Our script can check if they are already available
IMHO this isn't that complicated to do!
I mean, the use case described above makes total sense. Hundreds of migrations? Time for a new baseline!
Absolutely!
All of this is worth a try and shouldn't be too hard to do
Good tech hours fodder, I'd say.
Maybe after creating a little sample project to try out what's possible
We could add a lil' database to https://github.com/IQSS/dataverse-people
Last updated: Oct 30 2025 at 05:14 UTC