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@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@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@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@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@apache.org> wrote:

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

_______________________________________________
aerogear-dev mailing list
aerogear-dev@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev

_______________________________________________
aerogear-dev mailing list
aerogear-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev


_______________________________________________
aerogear-dev mailing list
aerogear-dev@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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/aerogear-dev