On 9/9/06, Ned Batchelder <[EMAIL PROTECTED]
> wrote:
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.
Thinking a little higher level, it feels like we should be avoiding the idea of a 'default' manager as much as possible. We let people define multiple managers, but we fall back to the default far too often.
One alternative that has been bouncing around in my head of late is to use 'cascading' managers - that is, if I start a query using the 'deleted_objects' manager, any related descriptors that are accessed should also use a 'deleted_objects' manager as a starting point.
If the related object doesn't have a 'deleted_objects' manager, there should be some mechanism of mapping 'deleted_objects' to some other alternative; if no mapping is provided, only then do you fall back to the default manager.
The mechanics of how this could be implemented are still a little hazy for me, but I think it would get around your problem. Comments?
Yours,
Russ Magee %-)
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.
Thinking a little higher level, it feels like we should be avoiding the idea of a 'default' manager as much as possible. We let people define multiple managers, but we fall back to the default far too often.
One alternative that has been bouncing around in my head of late is to use 'cascading' managers - that is, if I start a query using the 'deleted_objects' manager, any related descriptors that are accessed should also use a 'deleted_objects' manager as a starting point.
If the related object doesn't have a 'deleted_objects' manager, there should be some mechanism of mapping 'deleted_objects' to some other alternative; if no mapping is provided, only then do you fall back to the default manager.
The mechanics of how this could be implemented are still a little hazy for me, but I think it would get around your problem. Comments?
Russ Magee %-)
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
