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 see > http://groups.google.com/group/django-developers/browse_thread/thread/f433edf7b0ebdbcb/ > )
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 > at > http://www.djangoproject.com/documentation/0.96/model-api/#providing-initial-sql-data > 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 -~----------~----~----~----~------~----~------~--~---
