Re: [keycloak-dev] deprecated removals in future

From: "Bill Burke" <bburke(a)redhat.com&gt; To: "Stian Thorgersen" <stian(a)redhat.com&gt;, "Marek Posolda" <mposolda(a)redhat.com&gt; Cc: keycloak-dev(a)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.

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(a)redhat.com&gt; >> To: "Bill Burke" <bburke(a)redhat.com&gt;, "Stian Thorgersen" >> <stian(a)redhat.com&gt; >> Cc: keycloak-dev(a)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(a)redhat.com&gt; >>>>> To: "Stian Thorgersen" <stian(a)redhat.com&gt;, "Marek Posolda" >>>>> <mposolda(a)redhat.com&gt; >>>>> 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&gt; >>>>>>> To: "Bill Burke" <bburke(a)redhat.com&gt;, 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 >>>>> >>> >> >> -- Bill Burke JBoss, a division of Red Hat http://bill.burkecentral.com