quarkus-spring-data-jpa extension always loads import.sql, even in prod mode

[holly-cummins]

Describe the bug

This is long-standing behaviour (at least as far back as 3.10). When using the Spring Data compatibility extensions, we auto-load the contents of import.sql or data.sql.

Spring only does this for embedded databases.
'Normal' Quarkus only does this in dev and tests mode (which is a similar intention).
But with the Spring compatibility extensions, we do it even in prod.

To reproduce, comment out the disabling of the hibernate-orm load in https://github.com/quarkusio/spring-quarkus-perf-comparison/blob/main/quarkus3-spring-compatibility/src/main/resources/application.yml. (It may need quarkusio/spring-quarkus-perf-comparison#23 to merge first.) The integration tests will fail, because all of a sudden there's extra data from data.sql in the prod database.

I don't know if we should fix this since it would be a behaviour change to behaviour people might have been depending on, even though it feels more consistent. But raising this issue to track the discussion.

[quarkus-bot]

/cc @aureamunoz (spring), @edeandrea (spring), @geoand (spring)

[gsmet]

I don't know if we should fix this since it would be a behaviour change to behaviour people might have been depending on, even though it feels more consistent.

I don't think it's a good idea to import the data in production by default. I would mimick the behavior we have in plain Hibernate ORM and document the behavior change in the migration guide.

[geoand]

I'll take a look

[geoand]

I can't reproduce this in the Spring Data JPA quickstart. Basically, when using the same configuration as the Hibernate ORM quickstart, I see the two quickstarts behaving in the same way

Furthermore, we don't do anything special in the extension for properties; we just rely on the Hibernate ORM extension and map some property names.

[holly-cummins]

I can't reproduce this in the Spring Data JPA quickstart. Basically, when using the same configuration as the Hibernate ORM quickstart, I see the two quickstarts behaving in the same way

The quickstart masks the problem by always setting quarkus.hibernate-orm.sql-load-script=import.sql. That is, it adds configuration which forces the 'problem' behaviour.

(If we remove the config, it creates another problem, which is that the same test code can't be used for the integration tests and the quarkus tests, because we don't have an easy way of setting up databases for integration tests without contaminating the production behaviour; https://blog.knappi.org/0006-quarkus-integration-tests/ discusses that gap more, but that's a bigger design discussion.)

So setting up the reproduction with the quickstarts takes a few steps:

• Comment out the quarkus.hibernate-orm.sql-load-script=import.sql in the application properties
• By default, the *IT tests don't run, even with mvn verify. There's a command line argument to run them, but it behaves differently depending on the codebase, so I find it safest to just run the IT test with the green arrow in the IDE

Even with those two steps, like Georgios, I also couldn't reproduce. When running the integration tests, both were red, indicating that the data had not been loaded into the database in production mode.

But I can reproduce in the quarkus-spring-comparison project. What's going on?

On further investigation, the trigger is <extensions>true</extensions> and <goal>generate-code</goal> on the quarkus-maven-plugin configuration. If I add that to both the hibernate orm and spring data projects, I get a behaviour difference. The hibernate orm project still fails (no data pre-loaded), but the spring data project starts passing (data is pre-loaded in production mode).

This raises two questions:

• What's the mechanism for the behaviour difference?
• Why don't the quickstarts set <extensions>true</extensions> and the extra goals in their poms, given that new projects generated on code.quarkus.io do? The quickstart projects are also missing some goals.

            <plugin>
                <groupId>${quarkus.platform.group-id}</groupId>
                <artifactId>quarkus-maven-plugin</artifactId>
                <version>${quarkus.platform.version}</version>
                <extensions>true</extensions> <!-- Adding this line reproduces the bug, along with the goal below; it would be present in a project generated using a codestart -->
                <executions>
                    <execution>
                        <goals>
                            <goal>build</goal>
                            <goal>generate-code</goal> <!-- Adding this line reproduces the bug, along with the extensions=true; it would be present in a project generated using a codestart -->
                            <goal>generate-code-tests</goal> <!-- this line is missing in the quickstart, maybe we need to resync against the codestarts? -->
                            <goal>native-image-agent</goal> <!-- this line is missing in the quickstart, maybe we need to resync against the codestarts? -->
                        </goals>
                    </execution>
                </executions>
            </plugin>

Furthermore, we don't do anything special in the extension for properties; we just rely on the Hibernate ORM extension and map some property names.

I noticed the Quarkus code does set the quarkus.hibernate-orm.sql-load-script property; they're set with a low priority, but they might still override the-absence-of-properties. But I don't know if that's the mechanism or not. The lines in the PR I linked is only a year old, and the problem behaviour is older than that, so it's certainly not specifically that code which is the issue.

I've put my changes to make the quickstarts reproduce the problem into https://github.com/holly-cummins/quarkus-quickstarts/tree/reproducer-for-50792. So now we have two reproducers. :) With the quickstarts reproducer, you can see the diff is the same on the spring and hibernate projects, but the behaviour ends up being different; the hibernate-orm integration tests fail, because the db isn't populated, but the spring-data integration tests continue passing.