Re: [aerogear-dev] [UnifiedPush] cascase deletes ?

That sounds good On Fri, Nov 22, 2013 at 3:11 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt;wrote: > > On Nov 22, 2013, at 9:09 AM, Matthias Wessendorf <matzew(a)apache.org&gt; > wrote: > > > > > On Fri, Nov 22, 2013 at 3:05 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt;wrote: > >> i guess i'm think if you are using the admin ui and you delete a variant, >> the "are you sure you want to delete" dialog could include a "remove all >> installations" checkbox or something >> > > Ah - that would be an interesting option; > > > Assuming we have that checkbox-thingy...: > * Does clicking it mean we really nuke all that information? (or would > that mean they are moved to a NUKED_INSTALLATIONS table)? > > i say just NUKE em, if the database person wants to setup a trigger on > DELETE then thats there responsibility > > * Does not clicking mean they stay on that table? (so that some admin can > do the manual SQL fu for updating FK references to kinda (manually) > "relocate" them to a different variant? > > yup > > > > -M > > > > > >> >> On Nov 22, 2013, at 9:03 AM, Matthias Wessendorf <matzew(a)apache.org&gt; >> wrote: >> >> What do you mean with both ? >> >> >> >> On Fri, Nov 22, 2013 at 2:56 PM, Lucas Holmquist >> <lholmqui(a)redhat.com&gt;wrote: >> >>> is it possible to do both? >>> On Nov 22, 2013, at 8:38 AM, Matthias Wessendorf <matzew(a)apache.org&gt; >>> wrote: >>> >>> I was wondering if we should do cascading deletes for the device >>> metadata.... >>> >>> So, right now, when you are deleting a variant, all its installations >>> are NOT nuked, which helps when you are interested in collecting data.... >>> >>> >>> However we could nuke em, not sure.... >>> >>> Or... should we move them into a "DELETED" table? >>> >>> Users of the UnifiedPush Server might be interested in keeping the data >>> around, a bit .... >>> >>> I am not sure... >>> >>> >>> -Matthias >>> >>> >>> -- >>> 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 >>> >>> >>> >>> _______________________________________________ >>> 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 >> _______________________________________________ >> 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 >> > > > > -- > 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 > > > > _______________________________________________ > aerogear-dev mailing list > aerogear-dev(a)lists.jboss.org > https://lists.jboss.org/mailman/listinfo/aerogear-dev >