From: "Marek Posolda" <mposolda(a)redhat.com&gt; To: "Bill Burke" <bburke(a)redhat.com&gt;, keycloak-dev(a)lists.jboss.org Sent: Monday, April 27, 2015 11:37:18 PM Subject: Re: [keycloak-dev] generic model migration TBH, I am not sure if it's the way to go... The problem is that implementation like MigrationTo1_2_0_RC1 is directly using Model API. This can be problematic IMO because when your DB is in old version and you call the model operation like: realm.getClientNameMap().get(Constants.BROKER_SERVICE_CLIENT_ID); it could fail as source code is in newest version and hence JPA implementation expects the newest DB schema and fields in DB. But database is in old version and doesn't yet have those fields. That's why it seems to me that only stable way of migration is really the "native" calling of DB operations, which sucks but should work :-\ Marek On 27.4.2015 22:15, Bill Burke wrote: > I implemented this as a singleton data item in JPA or Mongo or File. I > jsut store the current version. Implementation is in > MigrationModelManager and it just checks the currently stored version > versus the deployed version. Its all hardcoded at the moment, but does > give some abstraction. I think it is good enough going forward. Don't > need anything fancy. _______________________________________________ keycloak-dev mailing list keycloak-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/keycloak-dev

Ah, sorry. I somehow missed the MigrationModelManager is executed after the DB schema is already updated. My bad. Shouldn't write emails so late in the night ;-) Marek On 28.4.2015 06:27, Stian Thorgersen wrote: > I reckon it works, but older updates will have to be refactored when > we change the model. > > ----- Original Message ----- >> From: "Marek Posolda" <mposolda(a)redhat.com&gt; >> To: "Bill Burke" <bburke(a)redhat.com&gt;, keycloak-dev(a)lists.jboss.org >> Sent: Monday, April 27, 2015 11:37:18 PM >> Subject: Re: [keycloak-dev] generic model migration >> >> TBH, I am not sure if it's the way to go... >> >> The problem is that implementation like MigrationTo1_2_0_RC1 is directly >> using Model API. This can be problematic IMO because when your DB is in >> old version and you call the model operation like: >> >> realm.getClientNameMap().get(Constants.BROKER_SERVICE_CLIENT_ID); >> >> it could fail as source code is in newest version and hence JPA >> implementation expects the newest DB schema and fields in DB. But >> database is in old version and doesn't yet have those fields. That's why >> it seems to me that only stable way of migration is really the "native" >> calling of DB operations, which sucks but should work :-\ >> >> Marek >> >> On 27.4.2015 22:15, Bill Burke wrote: >>> I implemented this as a singleton data item in JPA or Mongo or File. I >>> jsut store the current version. Implementation is in >>> MigrationModelManager and it just checks the currently stored version >>> versus the deployed version. Its all hardcoded at the moment, but does >>> give some abstraction. I think it is good enough going forward. Don't >>> need anything fancy. >> _______________________________________________ >> keycloak-dev mailing list >> keycloak-dev(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/keycloak-dev >>