Russ: Thanks for your reply! 1. I don't consider my views-as-models approach elegant at the implementation level, but: * it is dead simple to use once set up (it's just the Django model and database API) * it allows for limited aggregation support (views are created at install time, so real ad hoc reporting would have to be done with custom model methods) * it works with querysets since the aggregated columns are defined as Django model fields, so presenting a table of aggregated data with an arbitrary selection of rows only requires one actual database query (versus many queries when iterating over instances invoking a model method) * SQL code stays in SQL script files that are part of Django's design (sqlinitialdata) and stays out of my python code Ideally Django classes for the table and view functionality would share a common ancestor so they share an API, and table-specific behavior like delete_objects would be defined above the common (i.e. SELECT) functionality. Realistically, such a refactoring is unlikely before my next few projects are due (no sarcasm intended).
2. With hindsight, delete_objects() behavior of Django appears to be specifically desired by the developers so I'll just change my working copy to just check for a class attribute like "not_updatable", and abort batch deletes for related object classes with that attribute. Given the specific nature of my need (prevent cascading deletes of views) it will be much more efficient than calling an empty delete() method for each object. 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. I had hoped that the developers might be intrigued by the concept behind the hack (checking once per related class whether a user has overridden delete() and defaulting to the usual batch delete) because of the inherent object-functionality-versus-database- efficiency tension in an ORM. My hack offers options - the user can choose to give up database speed for object-level functionality - and options are always good as long as they are documented: "WARNING: Your database may slow to a crawl if you override delete()!" Checking if delete() was overridden is not a performance hit, so you don't lose anything by offering the option. For my application, aggregate reporting is far more common than deletion, so it needs to be efficient and convenient to code. 4. Regarding documentation, I will put in a ticket for the documentation on the relevant section http://www.djangoproject.com/documentation/model-api/#overriding-default-model-methods of the model-api page. That section invites people to override save() and delete() but only discusses save() and the implication (by omission) that overriding delete() is analogous is incorrect. 5. A big ongoing thanks to all of Django's contributors. You rock! Thanks for reading this. Cheers, Jeff On Jul 15, 1:24 am, "Russell Keith-Magee" <[EMAIL PROTECTED]> wrote: > On 7/13/07, JeffH <[EMAIL PROTECTED]> wrote: > > > > > This post relates to two separate Django issues that intertwined for > > me: > > 1. Lack of aggregation support in Django's ORM > > (I am delighted to > > seehttp://groups.google.com/group/django-developers/browse_thread/thread... > > ) > > For the record, I'm still keen to get aggregates supported in Django. > After a few distractions along the way (the unicode and oracle branch > merges), I believe Malcolm is currently working on the Query rewrite > that is the prerequisite for aggregates. Hopefully I will get a chance > to get some aggregates happening in the near future (but I've said > that before... :-) > > > I would like to hear from others how they are dealing with #1 and what > > their thoughts are about #2. > > When I need aggregates at the moment, I'm generally falling back into > raw SQL, or occasionally using the extra() clause on a queryset. Using > the 'extra' clause can get you where you want (annotated rows in a > database) by adding items to the select clause, which will appear as > extra attributes on objects from the query set. > > The difficulty comes in getting GROUP BY and HAVING clauses into your > query. This is because Django doesn't currently have support for these > clauses inside Q objects. You can cheat a little by exploiting the > fact that WHERE clauses are the last in the chain, but it's not > particularly robust approach to the problem. > > > Here goes: > > Experimenting with ways to add aggregated database information into my > > Django models, I came across a blog entry several weeks ago where the > > author (my apologies for not having the reference to cite) said they > > used VIEWs as Django Models, simply putting in the SQL code to drop > > the table and create a like-named VIEW in sql/model_name as discussed > > athttp://www.djangoproject.com/documentation/0.96/model-api/#providing-... > > for providing initial data. > > This is certainly a novel approach. > > On the general topic - adding Django support for DB-level views is > something I have had banging around in my brain for a while. Its an > obvious blind spot in the existing functionality of Django, and it > should be a relatively clean extension of the existing Model/metamodel > framework. > > However, I haven't looked at the problem in detail, and probably won't > have time to for a while. If someone else were to have a go at > implementing support for Views, I'm sure it would be looked upon > favorably. > > > My fix for this specific problem was to patch > > django.db.models.query.delete_objects() to see if the related model > > overrides the delete() method, and if so, use it instead of the > > existing batch SQL DELETE approach: > > I'm not sure I'm wild about this as a solution to the problem. > Deleting via a queryset is a 'bulk delete' operation, which is handled > quite separately from a normal delete. Django deliberately doesn't > call delete on individual objects in this case. If you are deleting a > lot of objects, calling delete on each object to be deleted can easily > be a very expensive operation, especially when you look at the > signalling and processing overhead. > > Yours, > Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
