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

[Douglas Campos]

On Mon, May 11, 2015 at 6:32 PM, Sebastien Blanc <scm.blanc at gmail.com>
wrote:

> That could be our solution no ?
> http://docs.jboss.org/keycloak/docs/1.2.0.CR1/userguide/html/Migration_from_older_versions.html#d4e3089
>
nope - the thing is moving data **between** datasources - this is only for
updating the DB schema to one datasource


>
>
> On Mon, May 11, 2015 at 11:29 PM, Douglas Campos <qmx at qmx.me> wrote:
>
>>
>>
>> On Mon, May 11, 2015 at 6:26 PM, Sebastien Blanc <scm.blanc at gmail.com>
>> wrote:
>>
>>> 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 ?
>>>
>> Migrator tool has no support for moving data between databases. TL;DR is
>> that this would be a PITA to get right. Better call would be KC having
>> something like export/import in JSON or somesuch.
>>
>>
>>>
>>>
>>> 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.
>>>>
>>>> >
>>>> > 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
>>>>
>>>
>>>
>>> _______________________________________________
>>> aerogear-dev mailing list
>>> aerogear-dev at lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
> _______________________________________________
> 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/20150511/9275c94e/attachment-0001.html