[keycloak-dev] deprecated removals in future

[Marek Posolda]

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 at redhat.com>
>>> To: "Stian Thorgersen" <stian at redhat.com>, "Marek Posolda" 
>>> <mposolda at redhat.com>
>>> Cc: keycloak-dev at 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 at redhat.com>
>>>>> To: "Bill Burke" <bburke at redhat.com>, keycloak-dev at 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 at lists.jboss.org
>>>>> https://lists.jboss.org/mailman/listinfo/keycloak-dev
>>>>>
>>>
>>> -- 
>>> Bill Burke
>>> JBoss, a division of Red Hat
>>> http://bill.burkecentral.com
>>>
>