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

[Douglas Campos]

On Thu, May 7, 2015 at 4:58 AM, Erik Jan de Wit <edewit at redhat.com> wrote:

> Even though keycloak and UPS used to share the schema I'm pretty sure
> that no data from UPS has ended up in Keycloak and visa versa. Because
> there is no direct hibernate keycloak class usage in UPS, therefore
> there is no way for UPS to store data in keycloak tables.
>
> So I propose to nuke the keycloak tables that are left over in the UPS
> schema.
>

Sure, what about the potential user data that might be still living there?
That's exactly why I'm bringing this to ag-dev :)


>
> On Thu, May 7, 2015 at 7:22 AM, Matthias Wessendorf <matzew at apache.org>
> wrote:
> >
> >
> > On Thursday, May 7, 2015, Douglas Campos <qmx at qmx.me> wrote:
> >>
> >>
> >>
> >> On Wed, May 6, 2015 at 10:26 PM, 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?
> >>
> >>
> >> UPS tables live alongside KC tables on the same schema/database
> >>
> >>>
> >>>>
> >>>> 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.
> >>
> >>
> >> We can, but you know how risky data migration is :)
> >
> >
> > back to one schema, for 1.1.0 and do clean separation on 1.2.0?
> >
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>>
> >>>>
> >>>> 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
> >>>
> >>> _______________________________________________
> >>> aerogear-dev mailing list
> >>> aerogear-dev at lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
> >>
> >>
> >
> >
> > --
> > Sent from Gmail Mobile
> >
> > _______________________________________________
> > aerogear-dev mailing list
> > aerogear-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>
> --
> Cheers,
>        Erik Jan
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20150507/c3bf7ac6/attachment.html