9:06 p.m.
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
9:35 p.m.
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
10:04 p.m.
It's not really all that silly and from a security standpoint granting a
user that normally only does CRUD requests the ability to alter the
structure of you database is probably not a good idea.
But you're right, there's probably no reason to migrate away from
liquibase. If update sql code could be provided or scripts to generate the
changes, that would be fine.
And I currently use the sql_output functionality to generate the sql
changelogs but it's a hassle, you have to:
- download the right version of the source code (or clone the master and
checkout the proper tag)
- modify the pom file in the jpa liquibase code to add the dependencies
for your database (cause i know you're not using h2)
- figure out why the "updateSql" task isn't working and update the pom
file again with the fix
I used it to upgrade from 1.3 -> 1.4 but 1.4 -> 1.5 is broke.
On Thu, Sep 24, 2015 at 3:35 PM, Scott Rossillo <srossillo(a)smartling.com>
wrote:
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
[image: Latest News + Events]
<https://app.sigstr.com/uc/55e5d41c6533390d03580000>
[image: Powered by Sigstr] <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
6:09 a.m.
We're definitively not removing Liquibase. Alternative is to manually write
SQL migration scripts for all supported databases. That's not happening as
the process is error prone and time consuming enough as it is.
I'd like to drastically change the schema so it doesn't need to change as
frequently. Either by:
* Store a whole realm as a json blob in a binary column
* Use generic tables with types and attributes (realm has attributes for
config options not individual columns)
Finally when schema changes we can make it simpler to use Liquibase to
create the upgrade script. We could add an 'manual' option to
'databaseSchema'. If set to this and the schema has changed Keycloak would
write the migration sql file (using Liquibase), then stop.
Rolling upgrades (and even live upgrades) are probably never going to
happen when the database schema changes. Changing the schema so it doesn't
change as frequently would at least make it possible to add that in the
future.
On 24 September 2015 at 22:04, Walker, Charles <cwalker(a)sumglobal.com>
wrote:
It's not really all that silly and from a security standpoint
granting a
user that normally only does CRUD requests the ability to alter the
structure of you database is probably not a good idea.
But you're right, there's probably no reason to migrate away from
liquibase. If update sql code could be provided or scripts to generate the
changes, that would be fine.
And I currently use the sql_output functionality to generate the sql
changelogs but it's a hassle, you have to:
- download the right version of the source code (or clone the master
and checkout the proper tag)
- modify the pom file in the jpa liquibase code to add the
dependencies for your database (cause i know you're not using h2)
- figure out why the "updateSql" task isn't working and update the pom
file again with the fix
I used it to upgrade from 1.3 -> 1.4 but 1.4 -> 1.5 is broke.
On Thu, Sep 24, 2015 at 3:35 PM, Scott Rossillo <srossillo(a)smartling.com>
wrote:
> 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
>
> [image: Latest News + Events]
> <https://app.sigstr.com/uc/55e5d41c6533390d03580000>
> [image: Powered by Sigstr] <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
>
>
>
_______________________________________________
keycloak-dev mailing list
keycloak-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/keycloak-dev
3136
days inactive
3137
days old
3 comments
4 participants
participants (4)
-
Bill Burke -
Scott Rossillo -
Stian Thorgersen -
Walker, Charles