[keycloak-dev] generic model migration
Marek Posolda
mposolda at redhat.com
Tue Apr 28 02:16:01 EDT 2015
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 at redhat.com>
>> To: "Bill Burke" <bburke at redhat.com>, keycloak-dev at 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 at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>
More information about the keycloak-dev
mailing list