#9358: .dates(...) only spitting out a single date, bug in queryset order
---------------------------------------------------+------------------------
Reporter: dokterbob | Owner:
mtredinnick
Status: assigned | Milestone: post-1.0
Component: Database layer (models, ORM) | Version: SVN
Resolution: | Keywords: dates
order .dates sqlite
Stage: Accepted | Has_patch: 1
Needs_docs: 0 | Needs_tests: 0
Needs_better_patch: 1 |
---------------------------------------------------+------------------------
Changes (by [EMAIL PROTECTED]):
* needs_better_patch: 0 => 1
Comment:
I have just done a few hours of messing around with the Django db code and
it seems to me that naming the date column will require an fairly
fundamental change in the way .order_by() parses its parameters (right now
it only looks in model.opts and extra_select). I can confirm however that
working with named aliases DOES work. Perfectly. :)
This again gave me the idea to put the Date() in extra_select instead of
select, which then automatically does the naming and also allows for named
sorting. The trouble here though is that:[[BR]]
* Setting select to [None] (line 381) causes the code not to query the
database at all. This seems like bad behaviour to me (sometimes you only
want extra data) but this is design decision which seems not related to
the current bug.[[BR]]
* Putting the Date() function directly in extra_select does not call its
as_sql method. Directly calling the as_sql function from add_date_select
would get us into trouble with pickling, I suppose.
It is very likely that similar problems will occur with sorting on
aggregate and other 'intelligent' columns as well.
Possible solutions for the problem include:[[BR]]
* Upgrading to an SQLite 3.6.4 (maybe even 3.6.3). In this version the
described problem is fixed. This seems a good workaround solution for
now.[[BR]]
* Enabling queries for empty selects and using named extra_select columns
for all kind of 'intelligence' like this. This means we have to call
.as_sql() in extra_select columns. Hereby we implement this kind of
functionality in a consistent way (alas, extra_select is what we would
have used ''before'' .dates() existed), so we would not have to do any
.order_by() workaround. Here .dates would simply be a piece of DB
abstraction upon the extra_select clausule.[[BR]]
''django/db/models/sql/subqueries.py'':
{{{
372 def add_date_select(self, field, lookup_type, order='ASC'):
373 """
374 Converts the query into a date extraction query.
375 """
376 result = self.setup_joins([field.name], self.get_meta(),
377 self.get_initial_alias(), False)
378 alias = result[3][-1]
379 select = Date((alias, field.column), lookup_type,
380 self.connection.ops.date_trunc_sql)
381 self.select = [select]
382 self.select_fields = [None]
383 self.select_related = False # See #7097.
384 self.extra_select = {}
385 self.distinct = True
386 self.order_by = order == 'ASC' and [1] or [-1]
}}}
--
Ticket URL: <http://code.djangoproject.com/ticket/9358#comment:6>
Django <http://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django updates" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-updates?hl=en
-~----------~----~----~----~------~----~------~--~---
