Skip to content

Flyway configuration ignores init-sqls when using spring.datasource.* properties #23392

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
ThomasKasene opened this issue Sep 17, 2020 · 1 comment
Assignees
Labels
type: bug A general bug
Milestone

Comments

@ThomasKasene
Copy link
Contributor

I'm trying to set the spring.flyway.init-sqls property to run a little statement before Flyway does anything with the migration scripts, while re-using the spring.datasource.* properties for the Flyway connection. That doesn't seem to be straight-forward, however.

I have the following in my application.yml:

spring:
  datasource:
    url: <url>
    username: <username>
    password: <password>
  flyway.init-sqls: SET ROLE '<username>'

Now, in FlywayAutoConfiguration.FlywayConfiguration there's a method that looks like this:

private DataSource configureDataSource(FluentConfiguration configuration, FlywayProperties properties,
        DataSourceProperties dataSourceProperties, DataSource flywayDataSource, DataSource dataSource) {
    if (properties.isCreateDataSource()) {
        String url = getProperty(properties::getUrl, dataSourceProperties::determineUrl);
        String user = getProperty(properties::getUser, dataSourceProperties::determineUsername);
        String password = getProperty(properties::getPassword, dataSourceProperties::determinePassword);
        configuration.dataSource(url, user, password);
        if (!CollectionUtils.isEmpty(properties.getInitSqls())) {
            String initSql = StringUtils.collectionToDelimitedString(properties.getInitSqls(), "\n");
            configuration.initSql(initSql);
        }
    }
    else if (flywayDataSource != null) {
        configuration.dataSource(flywayDataSource);
    }
    else {
        configuration.dataSource(dataSource);
    }
    return configuration.getDataSource();
}

This is the only place where I can find any usage of spring.flyway.init-sqls, but I'm noticing that properties.isCreateDataSource() only returns true if spring.flyway.url or spring.flyway.user are defined. Therefore, the code that uses init-sqls is never reached.

Is this expected behavior? I would have expected that as long as spring.datasource.url or spring.datasource.username is set, it's not necessary to also define spring.flyway.url or spring.flyway.user. It appears to work when I do this:

spring:
  datasource:
    url: <url>
    username: <username>
    password: <password>
  flyway:
    init-sqls: SET ROLE '<username>'
    url: ${spring.datasource.url}

I have a workaround for my case, but I'd like to hear if there's something I'm missing?

@spring-projects-issues spring-projects-issues added the status: waiting-for-triage An issue we've not yet triaged label Sep 17, 2020
@wilkinsona
Copy link
Member

wilkinsona commented Sep 18, 2020

Thanks for the report. When Spring Boot's initSql support was added (in Spring Boot 1.1) we were using Flyway 3.0 where it was only possible to specify SQL to initialise a connection when configuring Flyway's data source using a url, username, and password, rather than a DataSource instance. This changed in Flyway 5.2 but we missed it.

I see no reason not to apply spring.flyway.init-sqls irrespective of how the DataSource is being configured. I think we should have done that when we upgraded to 5.2.

@wilkinsona wilkinsona added type: bug A general bug and removed status: waiting-for-triage An issue we've not yet triaged labels Sep 18, 2020
@wilkinsona wilkinsona added this to the 2.2.x milestone Sep 18, 2020
@wilkinsona wilkinsona self-assigned this Sep 18, 2020
@wilkinsona wilkinsona modified the milestones: 2.2.x, 2.2.11 Sep 18, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: bug A general bug
Projects
None yet
Development

No branches or pull requests

3 participants