typecast_date(s) in db/backends/util.py crashes if s = None

[dmartin@…]

The error concerns the typecast_date(s) function in django/db/backends/util.py. If s is a NoneType instead of a null, the s.split('-') command causes the function to crash. This causes errors when trying to view some objects in the admin and also has been seen to cause errors with django.views.generic.date_based.archive_index. A simple try & except fixes the problem and doesn't affect normal behavior of the function. A .diff patch is attached.

[dmartin@…]

previous patch file was missing 'or None'

[Philippe Raoult]

Your patch would catch all exceptions which is not what you want. You'd better check for the specific value/type.

[Karen Tracey <kmtracey@…>]

That code is in trunk, it's not something change/added or even exclusively used by newforms-admin, so release for this ticket should be svn, not newforms-admin.

[Marc Fargas]

Maybe you would prefer to do:
if s is None: return None

of

if not s: return None

Anyway, can you give examples to see the bug in action? the only uses I see for this function is when working with the database so I can only thing of this when the database gives bad data. The best would be a testcase that causes the bug to raise but an example could do the job.

[Karen Tracey <kmtracey@…>]

I did see this bug in action, but it was a while ago, when I was still using an older level of MySQLdb (one where I needed to use the mysql_old Django database backend). In my case it happened when I had incompletely-specified dates in a MySQL date field, something like 2008-06-00. MySQL allows that, but that cannot be converted to a Python datetime object so this function in django/db/backends/util.py would throw an exception. Before pursuing it any further I first upgraded to the current MySQLdb and switched to the regular mysql backend, and found that this code was no longer called. Instead MySQLdb handled converting the date, and it caught the exception and returned None for these incompletely-specified dates.

So that's one way it can happen. Not sure what DB/data is causing the problem for the original poster.

[Marc Fargas]

We might think that this is one of the nice MySQL gotchas with date fields, I'll close as worksforme until the reporter can provide further details.
If his case is the same as yours then it's a DB fault, not Django's. (Another issue would be django allowing to insert/update the incorrect date).