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

On 22/11/2013 15:45, Lucas Holmquist wrote: i think that is their business logical and if they want to save something, they should be doing a database trigger or something, I agree with Luke here. Potentially this could be some kind of config file option somewhere if really needed. There could be cases where having the records is useful, but if you're already in that mindset you know what you are doing. Hylke On Nov 22, 2013, at 10:43 AM, Hylke Bons <hbons(a)redhat.com&gt; wrote: We should probably find out _why_ people might want to keep those records, and help them more appropriately in a nice way. That was the point I was trying to make. If we can't find any reasons, delete everything. Hylke On 22/11/2013 15:40, Matthias Wessendorf wrote: On Fri, Nov 22, 2013 at 4:33 PM, Lucas Holmquist <lholmqui(a)redhat.com&gt;wrote: > the admin ui is just one example, you could also use cURL. > > the problem is that the database will start to get a shit ton of > orphaned records if we don't have an option to cascade a delete > Or...we should simply ALWAYS remove all the things? If folks really want to 'safe' data (e.g. device metadata), they would be requesting that ? -Matthias > > > > On Nov 22, 2013, at 10:26 AM, Hylke Bons <hbons(a)redhat.com&gt; wrote: > > Then can you tell me the reasons why you'd want to do this? > If I'm interested in sending push notifications, why would I be > interested in database table rows? > > Just trying to figure out what problem you're actually trying to address > here, before cluttering the UI with extra things. :) > > Hylke > > On 22/11/2013 15:04, Matthias Wessendorf wrote: > > > > > On Fri, Nov 22, 2013 at 4:00 PM, Hylke Bons <hbons(a)redhat.com&gt; wrote: > >> I don't think a dialog here is a very elegant solution. If the usecase >> is to preserve the data for potential stats, >> > > not at all - it's about deleting the entities from the database - or not > > >> we should provide a nice way to view stats about push notifications, >> and not bother people with an implementation detail of the admin UI. >> > > not about stats at all; > > >> >> >> Hylke >> >> >> >> >> On 22/11/2013 14:56, Matthias Wessendorf wrote: >> >> >> >> >> On Fri, Nov 22, 2013 at 3:52 PM, Karel Piwko <kpiwko(a)redhat.com&gt; wrote: >> >>> I like the proposal, one question though: Will the nuke [checkbox] >>> option >>> provided from REST API as well? >>> >> >> yep :-) Otherwise I don't know how the UI would get the message to the >> server >> >> >>> >>> On Fri, 22 Nov 2013 15:16:41 +0100 >>> Matthias Wessendorf <matzew(a)apache.org&gt; wrote: >>> >>> > That sounds good >>> > >>> > >>> > On Fri, Nov 22, 2013 at 3:11 PM, Lucas Holmquist <lholmqui(a)redhat.com >>> >wrote: >>> > >>> > > >>> > > On Nov 22, 2013, at 9:09 AM, Matthias Wessendorf <matzew(a)apache.org >>> > >>> > > 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 >>> > > >>> > >>> > >>> > >>> >>> _______________________________________________ >>> 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 listaerogear-dev@lists.jboss.orghttps://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 listaerogear-dev@lists.jboss.orghttps://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 > -- Matthias Wessendorf blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf twitter: http://twitter.com/mwessendorf _______________________________________________ aerogear-dev mailing listaerogear-dev@lists.jboss.orghttps://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 listaerogear-dev@lists.jboss.orghttps://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