Re: How do you handle cascading deletes in your production apps?

On Dec 13, 2008, at 12:13 PM, Luke Plant wrote: > > On Friday 12 December 2008 01:06:18 Simon Litchfield wrote: >> +1. Definitely need some kind of cascade=False option somewhere. >> I'd argue it should be the default. > > -1 on it being default. Just because a foreign key may be nullable >

Re: How do you handle cascading deletes in your production apps?

On Fri, Dec 12, 2008 at 2:48 AM, James Bennett wrote: > > On Thu, Dec 11, 2008 at 7:06 PM, Simon Litchfield wrote: >> +1. Definitely need some kind of cascade=False option somewhere. I'd >> argue it should be the default. I have some production horror

Re: How do you handle cascading deletes in your production apps?

On Thu, Dec 11, 2008 at 7:06 PM, Simon Litchfield wrote: > +1. Definitely need some kind of cascade=False option somewhere. I'd > argue it should be the default. I have some production horror stories > which I'm sure I don't need to share. Keep in mind there is some prior

Re: How do you handle cascading deletes in your production apps?

+1. Definitely need some kind of cascade=False option somewhere. I'd argue it should be the default. I have some production horror stories which I'm sure I don't need to share. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google

Re: How do you handle cascading deletes in your production apps?

I'm not sure, but this ticket http://code.djangoproject.com/ticket/8168 "Pre Prepare For Delete" signal (i.e. do things BEFORE delete() tries to find all the relationships). Would be able to do all the custom stuff you'd want. "null out others", "bulk purges in custom queries", etc, etc .. i'd

Re: How do you handle cascading deletes in your production apps?

On Thu, Dec 11, 2008 at 12:36 PM, AcidTonic wrote: > > I hear from them that this design should > have no issues and they went further to question me how I am running > into problems All they wanted to see were queries and he said > rewrite it Then i informed him

Re: How do you handle cascading deletes in your production apps?

On Thu, Dec 11, 2008 at 12:06 PM, sed...@gmail.com wrote: ... > As of r8165 of Django (post qs-refactor), model_instance.delete() does > *not* null out instances with nullable foreign keys that point to the > about-to-be deleted instance. It deletes them instead. We have a >

Re: How do you handle cascading deletes in your production apps?

On Dec 11, 6:36 am, "Jeremy Dunck" wrote: > I'd like to make sure I understand what we're talking about here. > > model_instance.delete() nulls any instances with nullable FKs to the > deleted instance, right? > > The problem AFAICS, is that QuerySet.delete is not so careful,

Re: How do you handle cascading deletes in your production apps?

Trust me, my DBAs have been all over this problem for the past week. >From custom pl code, to a switch to oracle with more custom code, my DBAs are literally laughing at the performance of django We already use a custom cursor to create the IP objects after the subnet is created because even

Re: How do you handle cascading deletes in your production apps?

On Thu, Dec 11, 2008 at 10:49 AM, oggie rob <[EMAIL PROTECTED]> wrote: > > On Dec 10, 6:25 am, AcidTonic <[EMAIL PROTECTED]> wrote: >> I'm building an application to track IP addresses on many corporate >> networks with a single subnet having around 65535 rows for IP >> addresses. Now this

Re: How do you handle cascading deletes in your production apps?

On Dec 10, 6:25 am, AcidTonic <[EMAIL PROTECTED]> wrote: > I'm building an application to track IP addresses on many corporate > networks with a single subnet having around 65535 rows for IP > addresses. Now this app has thousands of those subnets which means > I have millions of rows for IP

Re: How do you handle cascading deletes in your production apps?

I believe any kind of delete will also clobber any models linked to or from the object getting deleted. One work around was to implement delete() on the model which nulls the relationships first. That works except querysets with more than one instance will NOT call the custom delete() method

Re: How do you handle cascading deletes in your production apps?

Couldnt we use the new Update() method on the queryset to NULL out the relationships prior to the bulk delete? At least that method would still apply in bulk vs 1by1 correct? Of course it wouldnt work when null isnt allowed but thats not the case for my application. Or could we add a flag to

Re: How do you handle cascading deletes in your production apps?

On Wed, Dec 10, 2008 at 3:04 PM, David Cramer <[EMAIL PROTECTED]> wrote: > > To be perfectly honest, I'm +1 on a solution. I didn't realize this > was happening either. > > Time to monkey-patch QuerySet's delete() method :) > > (I'm also a bit curious as to how its handling cascades in MySQL when

Re: How do you handle cascading deletes in your production apps?

To be perfectly honest, I'm +1 on a solution. I didn't realize this was happening either. Time to monkey-patch QuerySet's delete() method :) (I'm also a bit curious as to how its handling cascades in MySQL when it's not looping through each object) On Dec 10, 12:43 pm, "Karen Tracey" <[EMAIL

Re: How do you handle cascading deletes in your production apps?

On Wed, Dec 10, 2008 at 12:59 PM, AcidTonic <[EMAIL PROTECTED]> wrote: > > There is no anger here sir. I'm a rather sarcastic individual and I > guess there was a good dose there. > > I just cant for the life of me understand why this excellent framework > completely missed the point there. > >

Re: How do you handle cascading deletes in your production apps?

There is no anger here sir. I'm a rather sarcastic individual and I guess there was a good dose there. I just cant for the life of me understand why this excellent framework completely missed the point there. Is there a workaround that fixes the problem vs working around it? As in a django

Re: How do you handle cascading deletes in your production apps?

On Wed, Dec 10, 2008 at 11:05 AM, AcidTonic <[EMAIL PROTECTED]> wrote: > Frankly its as simple as NULLing out the id fields when the object > gets deleted. Thats all I want. Then write a patch and we'll consider it like we do everything else. That's the way open source gets produced: people who

Re: How do you handle cascading deletes in your production apps?

That is great except writing custom queries is quite time consuming considering the simplicity of the problem. Why even have an ORM if I have to write custom code to fix a problem CREATED by the framework. The underlying db doesnt even support cascade! Frankly its as simple as NULLing out the id

Re: How do you handle cascading deletes in your production apps?

Zach, You can always run custom delete operations if you want to work around the built in cascading. Take a look at the following example to see how you can do that: http://dpaste.com/92116/ Also, note that there is a ticket to add support for ON UPDATE and ON DELETE clauses to Django[1].

How do you handle cascading deletes in your production apps?

Currently the cascading delete functionality requires many users to change how their app works slightly to accommodate this "feature". I'm curious how people are disabling or working around this aspect of django. I've heard many people are implementing custom delete() methods on the model