> > 3. That said, my delete_objects() hack was an attempt to solve the > > more general problem of using an overridden delete() without any > > special flags while allowing for the possibility of model subclassing > > in the future, because it seemed that respecting an overridden > > delete() was an important end in itself from an object integrity > > perspective. > > To my mind, the better approach here would be to have proper support > for a 'read-only' query set that disables (or doesn't have) the delete > operation, rather than significantly changing the behaviour of bulk > deletes. Read-only objects/querysets would be an essential part of any > view support in Django.
Hmmm. I seem to have overgeneralized my problem and its solution. My real problem with using views right now is that Django implements (and therefore enforces) cascading deletes internally. I could easily override database-level delete cascade without having to hack on Django itself. I'm not concerned about intentional Manager-level bulk deletes. My specific error occurred when I blanked out all the core fields for an inline object in the Admin and saved the primary object. The inline object also has a one-to-one related view object that is caught up in the cascading delete code. I don't think the Manager- level delete() for related objects is invoked in situations like this --- though I'm speaking well beyond my knowledge level here. Regardless of how it is implemented, offering the user the ability to prevent cascading deletes of an object class either at the class definition or the field definition level would allow lots of powerful stuff without having to hack the Django core. In terms of the bigger picture, I think aggregation support should be handled at the queryset level, but view support would be much more powerful and easy to use if views are treated as model-like objects themselves because of their flexibility (for instance an updatable view onto a table in another database). Views are an advanced feature that not everybody needs - why not keep the changes minimal and put the onus on the user (let the DBA code the create view SQL file, and the application developer code the python)? In the short term, I would suggest the actual view creation be handled as raw user SQL in place of the usual model table creation (and that view creation be optional in case the view already exists on the database), and the user can specify that the view object is updatable, otherwise it defaults to [no saves/no deletes/no cascading deletes]. > Well, it is correct if you consider bulk-delete to be different to > delete. There is no bulk-save analog. Bulk delete (delete on a > queryset) is quite a different operation, that doesn't integrate with > the individual object delete. > > However, the distinction obviously isn't obvious to newcomers. > Suggestions on documentation improvements are always welcome. My > initial reaction is that if there is a need for improvement, its here: > > http://www.djangoproject.com/documentation/db-api/#deleting-objects > Good point. I'd say it should be explained there, and specifically mentioned in the model-api section on overriding. I'll put in a ticket. Cheers, Jeff --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~----------~----~----~----~------~----~------~--~---
