[aerogear-dev] Dealing with UPS Keycloak data post-datasource-split

Matthias Wessendorf matzew at apache.org
Tue May 12 01:24:24 EDT 2015


>From Stian on IRC

[07:20:00] *<matzew>* *stianst* DB migration from 1.0.5.Final to KC
1.2.0.CR1 is not working, like you hinted last night, right ? /cc
*abstractj*

[07:20:21] *<stianst>* matzew: yep, there's no chance it'll work



So, what does that mean? It means no DB migration support for KC database.
Perhaps that is OK,

I can't wrap my head around this now.


But the migration for our own schema should be possible w/ the help of the
migration tool - let's focus on that for now



On Tue, May 12, 2015 at 7:14 AM, Matthias Wessendorf <matzew at apache.org>
wrote:

>
>
> On Mon, May 11, 2015 at 11:11 PM, Bruno Oliveira <bruno at abstractj.org>
> wrote:
>
>> Sorry if I'm late for this discussion.
>>
>> On 2015-05-07, Matthias Wessendorf wrote:
>> > How about the following, not optimal, proposal:
>> >
>> > * get back to one data-source
>>
>> I'm not against about it, if it's for the benefit of the project.
>>
>> > * stick w/ Keycloak-1.1.0-final (in case updating to KC-1.2.0 makes
>> above
>> > item harder)
>>
>> I don't get why master must be reverted to 1.1.0 final. I think stable
>> release of KC must go in 1.0.x series of UPS, but on master, we must
>> stick with the latest greatest release of KC. Because is the only way to
>> work closely with KC team.
>>
>
> does their DB migration from their 1.0.5.Final to 1.2.0.CR1 work?
> If yes -> alright, let's go w/ KC 1.2..CR - if not, well it's not the end
> of the world to go back :-)
>
>
> Or, we just do NOT support any KC db migration, just ours - that's fine w/
> me...
>
>
>>
>> >
>> > I understand that a separation of the two is needed on the longer run -
>> it
>> > would be good if that's something on our agenda post 1.1.0 e.g. for
>> 1.2.0
>> >
>> > I think the above is a 'work around', which I could live with and buys
>> us
>> > time to truly think about a perfect separation.
>>
>> My 2 cents here and my humble opinion is the fact that we don't need
>> perfection,
>> only the correct. Today, split Keycloak and UPS would the most
>> correct thing to do. I'm not saying what we're doing here is dead wrong,
>> but
>> sooner or later the problem will hit us anyway.
>>
>> So maybe we should attack the problem now?
>>
>> >
>> >
>> >
>> >
>> >
>> >
>> > On Thu, May 7, 2015 at 3:26 AM, Matthias Wessendorf <matzew at apache.org>
>> > wrote:
>> >
>> > >
>> > >
>> > > On Wed, May 6, 2015 at 8:27 PM, Douglas Campos <qmx at qmx.me> wrote:
>> > >
>> > >> Howdy y'all!
>> > >>
>> > >> I'm revisiting migration strategies for UPS master, and we have a
>> tough
>> > >> situation to deal with.
>> > >>
>> > >> Since we have moved keycloak to its own DataSource, there are KC
>> > >> leftovers at UPS database which need to be cleaned up.
>> > >>
>> > >> 1) Any suggestions on how to provide a migration path?
>> > >>   Since the tables are intertwined with UPS tables, it's not a
>> matter of
>> > >> doing a db dump/restore...
>> > >>
>> > >
>> > > how are they intertwined? Is UPS stuff stored in KC tables, or vice
>> versa?
>> > >
>> > >
>> > >> 2) How to ensure we can safely get rid of the leftover tables on UPS
>> > >> DataSource?
>> > >>   I can easily provide migrations which just nuke the tables from the
>> > >> face of the earth,
>> > >>
>> > >
>> > > that's good, but
>> > >
>> > >
>> > >> but how to do this without data loss?
>> > >>
>> > >
>> > > I don't know :-) I wonder if we just can not move the data to a new
>> > > datasource.
>> > >
>> > >
>> > >
>> > >
>> > >
>> > >>
>> > >> Thoughts?
>> > >>
>> > >> _______________________________________________
>> > >> aerogear-dev mailing list
>> > >> aerogear-dev at lists.jboss.org
>> > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>> > >>
>> > >
>> > >
>> > >
>> > > --
>> > > Matthias Wessendorf
>> > >
>> > > blog: http://matthiaswessendorf.wordpress.com/
>> > > sessions: http://www.slideshare.net/mwessendorf
>> > > twitter: http://twitter.com/mwessendorf
>> > >
>> >
>> >
>> >
>> > --
>> > Matthias Wessendorf
>> >
>> > blog: http://matthiaswessendorf.wordpress.com/
>> > sessions: http://www.slideshare.net/mwessendorf
>> > twitter: http://twitter.com/mwessendorf
>>
>> > _______________________________________________
>> > aerogear-dev mailing list
>> > aerogear-dev at lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>
>> --
>>
>> abstractj
>> PGP: 0x84DC9914
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
>
> --
> Matthias Wessendorf
>
> blog: http://matthiaswessendorf.wordpress.com/
> sessions: http://www.slideshare.net/mwessendorf
> twitter: http://twitter.com/mwessendorf
>



-- 
Matthias Wessendorf

blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
twitter: http://twitter.com/mwessendorf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150512/05dcf374/attachment.html 


More information about the aerogear-dev mailing list