On Tue, Mar 23, 2010 at 5:53 AM, David Cramer <dcra...@gmail.com> wrote: > One of the recent changes in trunk was a change to how querysets were > cloned. Due to this, some old code we had is no longer working. This > was a custom aggregate which relied on "aggregate_select" (see below). > I believe the change I'm referring to is what is causing this, and I'm > unsure of what the proper approach should be now. Should this also be > considered a bug? If so, I'll go ahead and file a ticket.
I can't think of any obvious reason that clone() behavior should have changed, or why the aggregate you describe shouldn't be cloneable. I'm not aware of any existing report in this area, either, so yes, this should be reported as a bug. When you make your report, some things to keep in mind: * Make sure you tag it against milestone 1.2, because if this is a regression, we need to fix it before releasing 1.2. * Try to provide a minimal example that succeeds on 1.1, but fails on trunk - knowing the custom aggregate helps, but how complex does the query need to be in order to cause the problem you describe? Can you generate the same problem with a non-custom aggregate? * Can you clarify what is (is isn't) happening now that used to happen? Are you getting an error? Is the call to clone succeeding, but returning invalid results? * Can you narrow down the specific revision where the regression occurred? The most likely candidate is when multi-db landed (r11952), but if by some chance it was a different revision, it might make hunting down the problem a lot easier. 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-us...@googlegroups.com. To unsubscribe from this group, send email to django-users+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-users?hl=en.
