Generic archive_month view and inclusive ranges
James Bennett
"off-by-one"-style errors; see, for example, #992, nostalgic for me
because it was the first patch of mine ever accepted into Django.
Unfortunately, the view now includes too *much* instead of too little,
as mentioned in #3031, which hasn't really gone anywhere.
To see an example of the problem, consider this simplified model:
class Story(models.Model):
title = models.CharField(max_length=250)
pub_date = models.DateTimeField()
body = models.TextField()
If we have a Story with a pub_date of 2007-08-01 00:00:00, it will
show up in both the July and August archive_month views.
The reason for this is that the generic view does a "range" lookup,
and that becomes a BETWEEN in the SQL, using two dates: the first day
of the month and the first day of the next month.
I'm going to have to patch this for the buggy install that's
displaying this behavior (site with a workflow that typically sets
lots of things to be published at 00:00:00), but I'd like to get it
fixed upstream in Django as well; I'm just not certain of the best way
to go about it. Two options occur to me:
1. Change the lookup type, to do a 'gte' on the first day of the month
and an 'lt' on the first day of the next month.
2. Keep the lookup type, but switch the internals of the view to using
datetime.datetime objects instead of datetime.date, so that the
"last_day" variable can have one second subtracted from it and roll
back to 23:59:59 on the true last day of the month. Backwards
compatibility with the expectation of a datetime.date in the context
would be relatively easy.
Does anyone have a strong opinion one way or another?
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
Adrian Holovaty
> 1. Change the lookup type, to do a 'gte' on the first day of the month
> and an 'lt' on the first day of the next month.
>
> 2. Keep the lookup type, but switch the internals of the view to using
> datetime.datetime objects instead of datetime.date, so that the
> "last_day" variable can have one second subtracted from it and roll
> back to 23:59:59 on the true last day of the month. Backwards
> compatibility with the expectation of a datetime.date in the context
> would be relatively easy.
>
> Does anyone have a strong opinion one way or another?
Proposal #1 seems simpler, but this is not a strong opinion. :-)
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com
James Bennett
> Proposal #1 seems simpler, but this is not a strong opinion. :-)
The only thing that's keeping me from posting a patch for this right
now with option 1 is a lingering doubt about whether one of the
queries would be preferable; in the spirit of Simon's question about
SELECT 1 on the newer backends, could some of our gurus weigh in on
whether there's any appreciable difference on Oracle or MS-SQL between
the two options?
Malcolm Tredinnick
> On 8/13/07, Adrian Holovaty <holo...@gmail.com> wrote:
> > Proposal #1 seems simpler, but this is not a strong opinion. :-)
>
> The only thing that's keeping me from posting a patch for this right
> now with option 1 is a lingering doubt about whether one of the
> queries would be preferable; in the spirit of Simon's question about
> SELECT 1 on the newer backends, could some of our gurus weigh in on
> whether there's any appreciable difference on Oracle or MS-SQL between
> the two options?
My preference would be for option #1, since it feels neater (and the
"subtract one second approach" just narrows the gap; doesn't remove it
entirely).
Surprisingly, I think you might find SQLite is your main problem here.
We've had some bugs in the past because SQLite doesn't seem to cast
'YYYY-MM-DD' to 'YYYY-MM-DD 00:00:00' when it needs a datetime, or
something similar to that. There's one case I dimly remember where we
had to explictly add in or remove "00:00:00" for one check, but I can't
find it now (I would have expected it to be in
db/models/fields/__init__.py or db/backends/util.py).
So test carefully on SQLite, particularly on something that is a release
from, say, 8 months ago or so, since people won't have the absolutely
latest release all the time.
Regards,
Malcolm
--
Quantum mechanics: the dreams stuff is made of.
http://www.pointy-stick.com/blog/