You're right though. It will break and need to be refactored. But our
model is pretty stable.
On 4/28/2015 2:16 AM, Marek Posolda wrote:
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>
>> To: "Bill Burke" <bburke(a)redhat.com>,
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
>>