I am integrating liquibase in Spring boot project. I am planning to let hibernate run DB schema changes and run remaining DML queries via liquibase.
Is it good practice to manage DB changes via both Liquibase and
Hibernate at the same time ?
Are there any cons using the same?
Why not running everything from liquibase script? https://docs.spring.io/spring-boot/docs/current/reference/html/howto-database-initialization.html#howto-execute-liquibase-database-migrations-on-startup
Related
How can I use both in same SpringBoot project? Will it not create conflict which one is going to create tables?
Liquibase is Version Control System dedicated for track, version, and deploy database schema changes.
Hibernate is an object-relational mapping (ORM) tool for the Java programming language which provides a framework for mapping an object-oriented domain model to a relational database.
Yes of course you can use both in same Spring Boot project. Check this official guide liquibase + Hibernate for Using Liquibase with Hibernate.
I am trying to use Flyway. I understand that it is used for migration purposes. My use case is to load data from data.sql in my classpath. And I will want to add more data so I will need another data.sql file in future.
Is it possible to version just the data.sql file using Flyway? I am using Spring Boot to configure this.
it might be worth while starting with the Flyway Migrate documentation to help with understanding Flyway versioning scripts and naming conventions.
https://flywaydb.org/documentation/concepts/migrations
I want my application to use r2dbc drive when running and jdbc to handle the database with Liquibase. I have this as a reference. It is possible by adding the correct configuration inside application.properties and build.gradle.kts to achieve that. Update and everything is working but not automatically. Do you have any suggestions?Spring's reference
You have two options to use db migrations like Liquibase in a R2bc application.
Till now Liquibase did not support R2dbc, and by default R2dbc and Jdbc can not be activated in a single Spring boot application. In a reactive Spring Boot application, although you added a Jdbc starter, it is not activated by default.
But you can setup liquibase in a R2dbc application, and configure Liquibase Maven/Gradle plugin to migrate the database manually by Gradle tasks/Maven goals. See my example: liquibase-maven-r2dbc, make sure the db is running, and execute mvn liquibase:update in the project root.
See the official guide of Liquibase Maven PLugin, https://docs.liquibase.com/tools-integrations/maven/workflows/using-liquibase-maven-plugin-and-springboot.html
Use R2dbc Migrate directly, it is similar to Flyway but working with 2rdbc. See my example: r2dbc-migrate.
I am having a need where in a same spring boot application I need to use repo of Spring Data Mongo and Spring data jpa (postgres), during my initial testing I got runtime errors. While I debug more just wanted to check in same Spring Data Application can it have both repos for Postgres and MongoDB ?
Yes, you can have, make sure to add all dependency and create separate repositories for each data connection. I used MongoDB and MySql database it is working fine.
I would like to use Flyway as preferred way of database migration handling in my Spring Boot project (using current V1.2.1.RELEASE).
This is working fine so far however the integration with Spring Security using a JDBC DataSource seems to override the Flyway mechanism.
Following simple scenario:
Spring Boot 1.2.1
PostgreSQL 9.4.1
Flyway migration scripts for users, groups and authorities according to Spring Security documentation
Problem:
The Flyway migration scripts are not executed at startup as expected.
Maybe cause: It seems that Flyway is only executed at startup if the using Spring Boot project is also using JPA at least. Since Spring Security is based on plain JDBC, I've tried to temporary use the JDBC based database initialization scheme as described in Spring Boot docs (Chapter 68.3) which works, but (as documented) this way is like the 'poor man approach' and I'd really like to use Flyway also for these tables containing the User/Group/Authorities information.
Ok, after some further investigation I've found the problem:
Indeed, in a standard Spring Boot project the security context is initialized before any Flyway based migration takes place.
Normally this is not a big issue, but I've also used the AuthenticationManagerBuilder for creating a default admin user. This seems to be the wrong approach for creating such an initial user account.