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