DBAs don’t like applications modifying the database schema on startup. They want scripts
they can review. It’s a bit silly in some ways and I do not think it’s cause for alarm or
to move off Liquibase though. Liquibase really simplifies things a lot and it can generate
a SQL script to be applied before application startup:
http://www.liquibase.org/documentation/sql_output.html
As long as Keycloak will run the Java migration code if the DB is updated offline, it
should be fine.
There should be some documentation on upgrading in the user guide. It would be worth
documenting the correct way to upgrade, especially if you’re running a cluster or multiple
standalone servers sharing a database. I am pretty sure you can’t do a rolling upgrade but
someone may try it. ;)
Scott Rossillo
Smartling | Senior Software Engineer
srossillo(a)smartling.com
<
https://app.sigstr.com/uc/55e5d41c6533390d03580000>
<
http://www.sigstr.com/>
On Sep 24, 2015, at 3:06 PM, Bill Burke <bburke(a)redhat.com>
wrote:
An interesting suggestion from a user
On 9/24/2015 2:58 PM, Walker, Charles wrote:
> * move away from liquibase to manage the database schema. it's a nice
> tool but i haven't ran into many dba's that allow an application to
> "alter" the database. that meant i just had to go figure out another
> technology just to tease the sql out of it
I'm not sure how we could move away from liquibase. We would have to
provide a set of SQL scripts (cross-platform too) that would have to be
run on your database to upgrade keycloak. Then there is the Java-based
migrators that run after this to message the data with any new
transformations.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev