12:53 p.m.
The approach like MigrationModelManager or our current JSON migration is
cool and easy, but it stops working if you want to get rid of outdated
properties. For example if you want to remove RealmModel.getFoo() but
MigrateTo13.java is using getFoo property, you will see the errors with
new versions where property "foo" on RealmModel is not available anymore...
So what if we use something like "milestones" releases and support
migration just between those? For example milestone release can be 1.5 ,
1.10 and 1.15 (or 2.0 or whatever). Then if someone wants to migrate
from 1.0 to 1.12 he needs to go by migration path like:
- First migrate from 1.0 to 1.5
- Then migrate from 1.5 to 1.10
- Finally migrate from 1.10 to 1.12
For the 1.0 to 1.5 we can use the "easy" approach with keeping of all
the outdated properties on models and JSON representations. Then in 1.6
we will start from scratch and remove previous migrations and old
properties until 1.5. So migration to 1.6 is supported just from 1.5 etc.
For the 1.6 we will start from scratch with everything including
liquibase DDL scripts - to avoid situation when there are more and more
liquibase commands executed at initial boot.
Marek
On 17.7.2015 15:45, Bill Burke wrote:
You would still need to write a shit ton of raw SQL and JSON scripts
to convert from old models (1.0, 1.1, 1.2, 1.3, 1.4, etc...) to the
new Json realm model you want to instill.
I really worry that we'll be writing a crappy version of Mongo on top
of a relational store.
On 7/17/2015 9:21 AM, Stian Thorgersen wrote:
> Yeah, so let's drop the SQL stuff. We'll only have one single realm
> provider which is backed by json representations. Then we store json
> representations in Mongo or as blobs in the database.
>
> After that we only have to deal with one migration.
>
> ----- Original Message -----
>> From: "Bill Burke" <bburke(a)redhat.com>
>> To: "Stian Thorgersen" <stian(a)redhat.com>, "Marek
Posolda"
>> <mposolda(a)redhat.com>
>> Cc: keycloak-dev(a)lists.jboss.org
>> Sent: Friday, 17 July, 2015 2:33:31 PM
>> Subject: Re: [keycloak-dev] deprecated removals in future
>>
>> I'm not spending a week+ writing error prone raw JDBC and generic JSON
>> scripts. There's a lot of model migration code that would be a shit
>> ton
>> of raw SQL if you wanted to convert it. A new starting point would be
>> half a days work.
>>
>> On 7/17/2015 2:28 AM, Stian Thorgersen wrote:
>>> -1 It'll actually be more work to drop backwards compatibility for the
>>> model as we'd have to write a new "starting" point. For JSON
>>> representations it's just messy and has deprecated stuff in it
>>> because I
>>> did a crap job at implementing it. If we write a proper way to migrate
>>> json representations we won't need this and it'll just be a
>>> transformation
>>> pipeline that transforms the json to match the representation classes.
>>>
>>> ----- Original Message -----
>>>> From: "Marek Posolda" <mposolda(a)redhat.com>
>>>> To: "Bill Burke" <bburke(a)redhat.com>,
keycloak-dev(a)lists.jboss.org
>>>> Sent: Friday, 17 July, 2015 8:24:50 AM
>>>> Subject: Re: [keycloak-dev] deprecated removals in future
>>>>
>>>> +1
>>>>
>>>> Hopefully we can drop backwards compatibility for JSON reps
>>>> between 1.X
>>>> and 2.0 (ie. realm JSON representation exported in 1.X is not
>>>> supposed
>>>> to work to be imported in 2.0). That will allow us to drop old
>>>> metadata
>>>> from JSON and models and just create DB migration scripts for 1.X
>>>> to 2.0
>>>> migration.
>>>>
>>>> Marek
>>>>
>>>> On 17.7.2015 02:29, Bill Burke wrote:
>>>>> We're accumulating deprecated metadata in models and data model.
>>>>> Eventually we should draw a line in the sand and say we will only
>>>>> support migration from a certain version to current.
>>>>>
>>>>> i.e. Keycloak 2.0 would only allow migration from the last 1.x
>>>>> version.
>>>>>
>>>>> We need to clean all the old stuff out prior to product.
>>>>
>>>> _______________________________________________
>>>> keycloak-dev mailing list
>>>> keycloak-dev(a)lists.jboss.org
>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>
>>
>> --
>> Bill Burke
>> JBoss, a division of Red Hat
>> http://bill.burkecentral.com
>>