[aerogear-dev] [UnifiedPush] cascase deletes ?

Hylke Bons hbons at redhat.com
Fri Nov 22 10:43:35 EST 2013


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 at redhat.com 
> <mailto:lholmqui at redhat.com>> 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 at redhat.com
>     <mailto:hbons at redhat.com>> 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 at redhat.com
>>>     <mailto:hbons at redhat.com>> 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 at redhat.com <mailto:kpiwko at redhat.com>> 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 at apache.org
>>>>             <mailto:matzew at apache.org>> wrote:
>>>>
>>>>             > That sounds good
>>>>             >
>>>>             >
>>>>             > On Fri, Nov 22, 2013 at 3:11 PM, Lucas Holmquist
>>>>             <lholmqui at redhat.com <mailto:lholmqui at redhat.com>>wrote:
>>>>             >
>>>>             > >
>>>>             > > On Nov 22, 2013, at 9:09 AM, Matthias Wessendorf
>>>>             <matzew at apache.org <mailto:matzew at apache.org>>
>>>>             > > wrote:
>>>>             > >
>>>>             > >
>>>>             > >
>>>>             > >
>>>>             > > On Fri, Nov 22, 2013 at 3:05 PM, Lucas Holmquist
>>>>             <lholmqui at redhat.com <mailto:lholmqui at redhat.com>>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 at apache.org <mailto:matzew at apache.org>>
>>>>             > >> wrote:
>>>>             > >>
>>>>             > >> What do you mean with both ?
>>>>             > >>
>>>>             > >>
>>>>             > >>
>>>>             > >> On Fri, Nov 22, 2013 at 2:56 PM, Lucas Holmquist
>>>>             > >> <lholmqui at redhat.com
>>>>             <mailto:lholmqui at redhat.com>>wrote:
>>>>             > >>
>>>>             > >>> is it possible to do both?
>>>>             > >>> On Nov 22, 2013, at 8:38 AM, Matthias Wessendorf
>>>>             <matzew at apache.org <mailto:matzew at apache.org>>
>>>>             > >>> 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 at lists.jboss.org
>>>>             <mailto:aerogear-dev at lists.jboss.org>
>>>>             > >>> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>             > >>>
>>>>             > >>>
>>>>             > >>>
>>>>             > >>> _______________________________________________
>>>>             > >>> aerogear-dev mailing list
>>>>             > >>> aerogear-dev at lists.jboss.org
>>>>             <mailto: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
>>>>             <mailto:aerogear-dev at lists.jboss.org>
>>>>             > >> https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>             > >>
>>>>             > >>
>>>>             > >>
>>>>             > >> _______________________________________________
>>>>             > >> aerogear-dev mailing list
>>>>             > >> aerogear-dev at lists.jboss.org
>>>>             <mailto: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
>>>>             <mailto:aerogear-dev at lists.jboss.org>
>>>>             > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>             > >
>>>>             > >
>>>>             > >
>>>>             > > _______________________________________________
>>>>             > > aerogear-dev mailing list
>>>>             > > aerogear-dev at lists.jboss.org
>>>>             <mailto:aerogear-dev at lists.jboss.org>
>>>>             > > https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>>             > >
>>>>             >
>>>>             >
>>>>             >
>>>>
>>>>             _______________________________________________
>>>>             aerogear-dev mailing list
>>>>             aerogear-dev at lists.jboss.org
>>>>             <mailto: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  <mailto:aerogear-dev at lists.jboss.org>
>>>>         https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>>
>>>
>>>         _______________________________________________
>>>         aerogear-dev mailing list
>>>         aerogear-dev at lists.jboss.org
>>>         <mailto: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  <mailto:aerogear-dev at lists.jboss.org>
>>>     https://lists.jboss.org/mailman/listinfo/aerogear-dev
>>
>>     _______________________________________________
>>     aerogear-dev mailing list
>>     aerogear-dev at lists.jboss.org <mailto:aerogear-dev at lists.jboss.org>
>>     https://lists.jboss.org/mailman/listinfo/aerogear-dev
>
>
>     _______________________________________________
>     aerogear-dev mailing list
>     aerogear-dev at lists.jboss.org <mailto: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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/aerogear-dev/attachments/20131122/664f7504/attachment-0001.html 


More information about the aerogear-dev mailing list