Re: Custom default managers interfere with delete operations

[Ned Batchelder]

Russell Keith-Magee wrote: On 9/9/06, Ned Batchelder <[EMAIL PROTECTED] > wrote: I'm not familiar with the internals of this code, but here's a naive conception: since the default objects manager is made automatically by the ORM, couldn't it still be available internally for use in this case?  Whatever filtering is done by the app developer's default manager, it has to be defeated in order to properly delete related objects.  So why not skip the developer's default manager and use the default default manager (if you know what I mean). This approach sounds possible. My lingering concern is that there might be situations where using the user defined manager would be the correct behaviour for the object deletion algorithm. Your example is a bit of a weird case, born of the collision of two methods of 'deleting' objects (your boolean field representation and Django's database level deletion). I'm not entirely convinced that fixing the problem for your (somewhat specialised) use case wouldn't break it for all other legitimate uses. The details of my specific case are a bit of a red herring.  The fact remains that if the default manager does any filtering at all, then deleting an object may fail because its related objects will not all be deleted, and the database's referential integrity will prevent the deletion.  When looking for related obejcts to delete, you have to always get all of them.  No filtering allowed. -- Ned Batchelder, http://nedbatchelder.com --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~----------~----~----~----~------~----~------~--~---