Why 404?

3 views
Skip to first unread message

Jarek Zgoda

unread,
Aug 7, 2006, 4:29:45 PM8/7/06
to Django users
I am getting 404 with archive_day date-based generic view. I know that
some objects exist for specified day (they are present in archive_month
view), but I consequently get 404 if I specify a day.

My urlconf has an entry:
(
r'^(?P<year>\d{4})/(?P<month>\d{2})/(?P<day>\d{2})/$',
'django.views.generic.date_based.archive_day',
item_dict
),
where item_dict contains only queryset, date_field and month_format (I
use "%m"). The dictionary for archive_month view has identical
definition and contains objects with specified date.

I am stuck here. How can I debug this to get any clue?

Cheers
Jarek Zgoda

Steven Armstrong

unread,
Aug 7, 2006, 5:22:56 PM8/7/06
to django...@googlegroups.com

Hi Jarek

Don't know if this is related to your problem, but if you're using
sqlite the patch at [1] may help.

If this does solve your problem, and you have a moment, you could add
some more background info about the bug to that ticket and confirm that
the patch worked. I was in a rush when I created it and haven't yet
taken time to add some more info for the devs.

cheers
Steven

[1] http://code.djangoproject.com/ticket/2471

Marius Ursache

unread,
Aug 7, 2006, 6:01:07 PM8/7/06
to django...@googlegroups.com

If the only records you inserted are today, make sure you have the
correct timezone set.

I had a similar problem (not seeing the records I just inserted into
database - actually they were the only one) because I left the
timezone variable set to "America/Chicago" and i live in Europe (and
my timezone is Chicago + 8). So the date filter considered all the
records 'in the future'.

Hope that helps.

--
m.
http://marius.me.uk/

Jay Parlar

unread,
Aug 7, 2006, 6:39:37 PM8/7/06
to django...@googlegroups.com
On 8/7/06, Marius Ursache <ursache...@gmail.com> wrote:
> I had a similar problem (not seeing the records I just inserted into
> database - actually they were the only one) because I left the
> timezone variable set to "America/Chicago" and i live in Europe (and
> my timezone is Chicago + 8). So the date filter considered all the
> records 'in the future'.
>

Note that 'allow_future' is now a valid argument to those generic views.

My guess though is that Steven is right: SQLite is causing your
problem. I was having the exact same issue the other day (archive_day
wasn't working) and a switch to MySQL fixed it.

Jay P.

Jarek Zgoda

unread,
Aug 8, 2006, 7:12:48 AM8/8/06
to Django users
Jay Parlar wrote:

Thank you all. My timezone is set to my current TZ (Europe/Warsaw).
Setting allow_future = True has no effect, but I'll try with other
database backend.

I was wondering if the time part of datetime object may have any impact
on this (some databases insert '00:00:00' as the time part for dates
only, other insert current time), but looking at data from sqlite
interactive client I see '2006-08-07 00:00:00'.

Anyway, thanks for advice.

Cheers
Jarek Zgoda

Jarek Zgoda

unread,
Aug 8, 2006, 7:18:39 AM8/8/06
to Django users
Steven Armstrong wrote:

> Don't know if this is related to your problem, but if you're using
> sqlite the patch at [1] may help.

Yes, I use SQLite.

> If this does solve your problem, and you have a moment, you could add
> some more background info about the bug to that ticket and confirm that
> the patch worked. I was in a rush when I created it and haven't yet
> taken time to add some more info for the devs.

Will try and report. Anyway, some Trac description of what this patch
fixes would be nice, as I am not a Python guru and I am already lost in
Django sources, so my chances to understand this from simple looking at
the diff are minimal...

Cheers
Jarek Zgoda

Jarek Zgoda

unread,
Aug 8, 2006, 7:45:54 AM8/8/06
to Django users
Steven Armstrong wrote:

> Don't know if this is related to your problem, but if you're using
> sqlite the patch at [1] may help.
>
> If this does solve your problem, and you have a moment, you could add
> some more background info about the bug to that ticket and confirm that
> the patch worked. I was in a rush when I created it and haven't yet
> taken time to add some more info for the devs.

This patch didn't solve my problem, I see no difference in behaviour.

The object with date field value of 2006-08-07 definitely exists (it is
listed in month view), but trying to make a view of objects at URL
2006/08/07/ results in empty list, thus 404 if allow_empty == False. My
urlconf contains entry for
^(?P<year>\d{4})/(?P<month>\d{2})/(?P<day>\d{2})/$, so above given URL
should add items 'year': '2006', 'month': '08', 'day': '07' to generic
view call arguments list. Month format is already '%m', day format is
default. It seems that SQLite3 database contains character value of
'2006-08-07' in this field.

Will try with MySQL, although it's a bit of overkill to me.

Cheers
Jarek Zgoda

Steven Armstrong

unread,
Aug 8, 2006, 12:48:50 PM8/8/06
to django...@googlegroups.com

This is exactly the problem that the patch fixes.
In MySQL and friends a DateField is represented as '2006-08-07 00:00:00'
while in sqlite it's just '2006-08-07'.

The patch changes the archive_day view to test if it's dealing with a
DateField or a DateTimeField and builds the sql lookup args depending on
that.

Have you nuked any *.pyc files still lying around after applying the patch?

I had the exact same symptoms that you're describing and the patch
solved the problem.

hope this helps
cheers
Steven

Jarek Zgoda

unread,
Aug 8, 2006, 2:41:14 PM8/8/06
to Django users
Steven Armstrong wrote:

> Have you nuked any *.pyc files still lying around after applying the patch?

That was it, thanks. Did a clean SVN checkout and your patch works
fine.

Any chance for anybody else to check & review this patch? It would be
nice to have such problem fixed...

Cheers
Jarek Zgoda

DvD

unread,
Dec 8, 2006, 11:21:10 AM12/8/06
to django...@googlegroups.com
Hi everyone, I keep on getting a weird problem on my project.
I use date based generic views to retrieve events for a web site, when I
use archive_index and archive month no problems, but when i use
archive_day or detail_object I keep on getting a 404.

I searched over the mailing list to find someone else who has got the same
problem as mine, Jare Zgoda, but he used to use SQLite and I am using
MySQL with a correct time zone setting.

Here is the code:

---
detail_info_dict= {
'queryset': Evento.objects.all(),
'date_field': 'pub_date',
'extra_context': general_extra_context,
'allow_future': True,
'month_format': '%m',
}
general_info_dict= {
'queryset': Evento.objects.all(),
'date_field': 'pub_date',
'extra_context': general_extra_context,
'allow_future': True,
'allow_empty': True,
'month_format': '%m',
}
index_info_dict= {
'queryset': Evento.objects.all(),
'date_field': 'ins_date',
'extra_context': index_extra_context,
'allow_empty': True,
}

urlpatterns= patterns('django.views.generic.date_based',
(r'^(?P<year>\d{4})/(?P<month>\d{1,2})/(?P<day>\d{1,2})/(?P<object_id>\d{1,10})/$',
'object_detail', detail_info_dict),
(r'^(?P<year>\d{4})/(?P<month>\d{1,2})/(?P<day>\d{1,2})/$',
'archive_day', general_info_dict),
(r'^(?P<year>\d{4})/(?P<month>\d{1,2})/$', 'archive_month',
general_info_dict),
(r'^/?$', 'archive_index', index_info_dict),
)
---

On the "Evento" class I use this code to retrieve the absolute_url of the
events:

---
def get_absolute_url(self):
return "/%s/%s" % (self.pub_date.strftime("%Y/%m/%d"), self.id)
---

Hope anyone can help me...

Thanks in advance,
David
--
Brokenseal di Callegari Davide

Le informazioni contenute in questo messaggio di posta elettronica sono
riservate e confidenziali e ne e' vietata la diffusione in qualunque modo
eseguita. Qualora Lei non fosse la persona a cui il presente messaggio e'
destinato, La invitiamo ad eliminarlo e a non utilizzare in alcun caso il
suo contenuto, dandone gentilmente comunicazione al mittente.


The information contained in this e-mail and any attachments is
confidential and may well also be legally privileged. If you are not among
the named recipients, please notify the sender immediately by reply e-mail
and then delete this message from your system, do not use the contents for
any purpose whatsoever nor disclose them to anyone else.


Rif. D.L. 196/2003.

Reply all
Reply to author
Forward
0 new messages