Re: Issue with aggregate_select changes
On Tue, Mar 23, 2010 at 5:26 AM, Russell Keith-Magee wrote: > On Tue, Mar 23, 2010 at 5:53 AM, David Cramer 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. > > I'd guess it is due to this change: http://code.djangoproject.com/changeset/12830 Karen -- 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.
Re: Issue with aggregate_select changes
On Tue, Mar 23, 2010 at 5:53 AM, David Cramer 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.
Re: Issue with aggregate_select changes
I suppose I should post the full version, since my simplified attempt didnt work :) class ICount(Aggregate): name = 'ICOUNT' sql_function = 'COUNT' sql_template = '%(function)s(LOWER(%(field)s))' is_ordinal = True def __init__(self, lookup, **extra): self.lookup = lookup self.extra = extra def _default_alias(self): return '%s__%s' % (self.lookup, self.__class__.__name__.lower()) default_alias = property(_default_alias) def add_to_query(self, query, alias, col, source, is_summary): super(ICount, self).__init__(col, source, is_summary, **self.extra) query.aggregate_select[alias] = self On Mar 22, 4:53 pm, David Cramer 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. > > class ICount(Aggregate): > sql_function = 'COUNT' > sql_template = '%(function)s(LOWER(%(field)s))' > is_ordinal = True > name = 'ICOUNT' > > def add_to_query(self, query, alias, col, source, is_summary): > super(ICount, self).__init__(col, source, is_summary, > **self.extra) > query.aggregate_select[alias] = self -- 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.
Issue with aggregate_select changes
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. class ICount(Aggregate): sql_function = 'COUNT' sql_template = '%(function)s(LOWER(%(field)s))' is_ordinal = True name = 'ICOUNT' def add_to_query(self, query, alias, col, source, is_summary): super(ICount, self).__init__(col, source, is_summary, **self.extra) query.aggregate_select[alias] = self -- 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.
