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

>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(a)apache.org&gt; wrote: > > > On Mon, May 11, 2015 at 11:11 PM, Bruno Oliveira <bruno(a)abstractj.org&gt; > 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(a)apache.org&gt; >> > wrote: >> > >> > > >> > > >> > > On Wed, May 6, 2015 at 8:27 PM, Douglas Campos <qmx(a)qmx.me&gt; 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(a)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(a)lists.jboss.org >> > https://lists.jboss.org/mailman/listinfo/aerogear-dev >> >> >> -- >> >> abstractj >> PGP: 0x84DC9914 >> _______________________________________________ >> aerogear-dev mailing list >> aerogear-dev(a)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(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/aerogear-dev