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
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
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/
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.
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
> 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
> 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
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
> 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
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.