[keycloak-dev] deprecated removals in future

[Stian Thorgersen]

----- 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: Monday, 20 July, 2015 5:21:56 PM
> Subject: Re: [keycloak-dev] deprecated removals in future
> 
> They would upgrade to 1.5 first, then upgrade to 2.x.

In the example I gave they are not able to upgrade to 1.5 as there was a bug in the migration that made it not work the db they use. So we'd have to release a 1.5.1 for them.

I seriously don't think we should be putting these kinda off restrictions in place. It's going to come back and bite us.

> 
> On 7/20/2015 12:37 AM, Stian Thorgersen wrote:
> > -1000 A user should be allowed to upgrade from any version, not only
> > because of convenience, but also because there may be no other option. For
> > example we've had users that have been unable to upgrade to certain
> > versions in the past due to bugs in the migration stuff. What if someone
> > is stuck on an old version 1.2, while version 1.5 is required to upgrade
> > to version 2.0 and the user can't upgrade to 1.3, 1.4 or 1.5? We'd have to
> > do a 1.2.1 release for the user just to allow them to upgrade.
> >
> > ----- Original Message -----
> >> From: "Marek Posolda" <mposolda at redhat.com>
> >> To: "Bill Burke" <bburke at redhat.com>, "Stian Thorgersen"
> >> <stian at redhat.com>
> >> Cc: keycloak-dev at lists.jboss.org
> >> Sent: Friday, 17 July, 2015 7:53:44 PM
> >> Subject: Re: [keycloak-dev] deprecated removals in future
> >>
> >> 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
> >>>>>
> >>>
> >>
> >>
> 
> --
> Bill Burke
> JBoss, a division of Red Hat
> http://bill.burkecentral.com
>