OHDSI Home | Forums | Wiki | Github

Exception Given for Existing Sequence (migration error) for webapi in Broadsea

I’m trying to get Broadsea to point to an existing webapi and CDM schemas that I have in PostgreSql on my localhost.

When webapi starts up in Docker I get the error shown below.

I’m assuming it has something to do with the section of parameters shown below and there is someplace in my schema I can check for the correct information?

The full .yml configuration file and full stack trace are attached.

docker-compose.yml.txt (3.6 KB)
stack-trace.txt (35.6 KB)


FLYWAY_LOCATIONS: classpath:db/migration/postgresql
FLYWAY_TABLE: schema_history
flyway_baselineVersionAsString: “” # this env var is case sensitive


2023-04-18 05:27:55 Migration V2.2.5.20180215105415__separate-sequences.sql failed
2023-04-18 05:27:55 --------------------------------------------------------------
2023-04-18 05:27:55 SQL State  : 42P07
2023-04-18 05:27:55 Error Code : 0
2023-04-18 05:27:55 Message    : ERROR: relation "cca_sequence" already exists
2023-04-18 05:27:55 Location   : db/migration/postgresql/V2.2.5.20180215105415__separate-sequences.sql (/var/lib/ohdsi/webapi/WEB-INF/classes/db/migration/postgresql/V2.2.5.20180215105415__separate-sequences.sql)
2023-04-18 05:27:55 Line       : 1
2023-04-18 05:27:55 Statement  : CREATE SEQUENCE webapi.cca_sequence
2023-04-18 05:27:55 
2023-04-18 05:27:55 2023-04-18 09:27:55.840 INFO main org.springframework.boot.autoconfigure.logging.AutoConfigurationReportLoggingInitializer - [] - 
2023-04-18 05:27:55 
2023-04-18 05:27:55 Error starting ApplicationContext. To display the auto-configuration report re-run your application with 'debug' enabled.
2023-04-18 05:27:55 2023-04-18 09:27:55.844 ERROR main org.springframework.boot.SpringApplication - [] - Application startup failed
2023-04-18 05:27:55 org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'shiroFilter' defined in class path resource [org/ohdsi/webapi/ShiroConfiguration.class]: Unsatisfied dependency expressed through method 'shiroFilter' parameter 0; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'flyway' defined in class path resource [org/ohdsi/webapi/FlywayConfig.class]: Invocation of init method failed; nested exception is org.flywaydb.core.internal.command.DbMigrate$FlywayMigrateSqlException: 
2023-04-18 05:27:55 Migration V2.2.5.20180215105415__separate-sequences.sql failed
2023-04-18 05:27:55 --------------------------------------------------------------

That error indicates that the migration already was performed (by creating the sequence) but the migration metadata didn’t indicate that the migration was performed.

One element of the configuration is the FLYWAY_BASELINEONMIGRATE: "true", paramater, and I checked that we don’t allow that to be changed in the core ‘application.properties’ files (it forces the true value). I checked the documentation on this parameter and found these docs.

This indicates that flyway will do a ‘baseline’ when we migrate into a non-empty schema. But, the schema should always start off empty, so I’m not sure what the Broadsea implementation was trying to accomplish here. @lee_evans , can you provide details here?

I would like to use an existing webapi and an existing cdm schema that I’ve built outside of Broadsea. It sounds like this might not be possible and that I can use my own cdm schema (e.g. in Databricks) but will need to let Broadsea build the webapi schema?

I was unclear on this setting as well, so I just kept it as-is for the upcoming v3 of Broadsea. What would you recommend for this?

It is possible – just need to sort out this setting.

In Broadsea 3 (upcoming), you can specify a webapi schema hosted separately or you can have Broadsea build it. You can then add CDM sources just the same as it works without Broadsea, by adding records to the webapi source/source_daimon tables (although cleanest approach is via the Atlas GUI).

1 Like

I think the recommendation is that broadsea should just come pre-packaged with an empty webapi schema that has proper permissions assigned, but completely empty. Then the migration scripts can do all the work. I think what the OP error is reporting is taht somehow the webapi was populated with tables but Flyway didn’t do it, so it thought it had to do it again.