On 1/26/06, Russell Keith-Magee <[EMAIL PROTECTED]> wrote: > On 1/26/06, Adrian Holovaty <[EMAIL PROTECTED]> wrote: > > Yeah -- I'm not 100% comfortable with coupling object instances to a > > manager. It seems a bit wonky... > > I'll grant that the mechanism of using the 'default' manager for the > delete is not entirely wonk-free.
Actually - I partially take that back. While I was working on the model validation code, I had occasion to have a bit a closer look more at the existing object-manager coupling. The following methods all defer to the manager for their operation: _get_next_or_previous_by_FIELD _get_next_or_previous_in_order _get_foreign_key_object _get_related _get_related_many_to_many These methods all use the manager for exactly the same reason, in exactly the same way - they use _default_manager as a source for SQL queries/operations. This suggests to me that either: 1) The bulk delete patch is ok, because it does the same thing other methods do, or 2) We need to look at the relationship between object and manager to remove the need for/use of _default_manager throughout the model. That said - I'll wait until the new Manager/descriptor stuff has settled down before I get back into this patch. It occurred to me that:: del Articles.objects.filter(name_startswith='foo') is a bulk delete syntax that becomes available with the new descriptor syntax, and the safety mechanism can be achieved by disallowing:: del Article.objects rather than by handling the wierd non-interpreted DELETE_ALL kwarg. Russ Magee %-)
