On Mon, 2008-08-18 at 17:20 -0300, Ramiro Morales wrote: > Matt, > > On Mon, Aug 18, 2008 at 4:04 PM, Matt Boersma <[EMAIL PROTECTED]> wrote: > > > > > Here is Leo Soto's buildbot, so you can see what I'm talking about: > > http://certenium.ingenium.cl:8080/hudson/job/django-trunk/ > > > > I'll do my best to fix some of these as time permits, but I'm hoping > > others will pull together to rectify this quickly. Thanks! > > Some of these failures might be related to the changes in the `extra_select` > (and `extra_select_params` that got deleted) Query class attributes introduced > in r8426 because, as you know, the Oracle backend (and the MS SQL Server > backends) uses `extra_select` to insert a synthetic placeholder needed to use > the ORDER_BY function to emulate LIMIT+OFFSET. > > FWIW, in my work on a MS SQL Server backed I circumvented the bulk of the > problem by accident (actually, because this is one of the things that allowed > me to get a whole bunch of the Django test suite to start passing on SQL > Server 2005 whose SQL dialect also has the ORDER_BY function) some time ago by > migrating away from using `extra_select` to using the `ordering_aliases` > attribute to handle the placeholder by appending to it:
Is that robust enough for you? Would it be better/easier if the extra_select dictionary -- which right now stores (select-string, params) pairs -- was to also have a flag in there to say whether it was inserted by the main query or by the backend wrapping class? What I'm thinking about is something like making Query.add_extra() put in triples (select-string, params, 1), where "1" is the flag to say it is part of the main query. Then, if you need to add bonus stuff to handle the ordering, you can put in (select-string, params, 2), for example. That extra_select attribute is internal and we change it to accommodate that sort of situation if it makes things easier. I don't want to mess more than necessary with internal Query structures after 1.0, but I'm aware there is this need to write nested selects to get limit/offset equivalence in some backends (MS SQL, Oracle, etc), so if there's an alternate internal structure that helps there, please ask. The one approach I'd personally be a little resistant to is having another attribute just for the limit/offset extra columns, since that's special casing based on the requirements of one approach in backends (and, yes, we already special case with the standard LIMIT/OFFSET stuff, but I'd like to keep to a small number of special cases, if possible). But if that's really necessary, so be it. There are hooks already in place that are only used by one other thing right now, but can't be avoided, so it's not something I have moral objections to or anything like that. Regards, Malcolm --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~----------~----~----~----~------~----~------~--~---
