4:38 p.m.
On Mon, May 11, 2015 at 6:32 PM, Sebastien Blanc <scm.blanc(a)gmail.com>
wrote:
That could be our solution no ?
http://docs.jboss.org/keycloak/docs/1.2.0.CR1/userguide/html/Migration_fr...
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(a)qmx.me> wrote:
>
>
> On Mon, May 11, 2015 at 6:26 PM, Sebastien Blanc <scm.blanc(a)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(a)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(a)apache.org>
>>> > wrote:
>>> >
>>> > >
>>> > >
>>> > > On Wed, May 6, 2015 at 8:27 PM, Douglas Campos <qmx(a)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(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
>>>
>>
>>
>> _______________________________________________
>> aerogear-dev mailing list
>> aerogear-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>
>
> _______________________________________________
> aerogear-dev mailing list
> aerogear-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
_______________________________________________
aerogear-dev mailing list
aerogear-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev