DateTimeField queryset returning None in Django

Question

I am trying to create a queryset for getting the values of a DateTimeField which is DATETIME in the DB.

The class in models.py:

class ChangeMetrics(models.Model):
    id = models.IntegerField(primary_key=True)
    file_id = models.ForeignKey(File, db_column = 'file_id')
    version_id = models.ForeignKey(Version, db_column = 'version_id')
    function_id = models.ForeignKey(Function, blank=True, db_column = 'function_id')
    date = models.DateTimeField(blank=True, null=True)
    user = models.TextField(blank=True)
    changed = models.IntegerField(blank=True, null=True)

The field in the DB:

date DATETIME

The tuples are populated in the database and running SQL queries directly on the DB is working perfectly.

This is the queryset I am currently using in Django:

queryset = ChangeMetrics.objects.filter(~Q(changed=None), ~Q(date=None), ~Q(version_id=None))

I have tried a raw query and also a version of the query that uses exclude(), but that still returns None for date.

I am accessing the entries in the queryset through a for loop and simply accessing date through entry.date inside the for loop.

Edit: Django version 1.6.5 I have also tried getting the values through the Django shell, to no success.

Any ideas on what could be wrong?

Answer 1

not sure if you were able to figure this out, but I just had this problem and was able to fix it.

So, Django migrations were creating the column in the DB as datetime(6) instead of datetime. This was causing the Django models to fail to instantiate the Datetime object.

ALTER TABLE `my_table` 
MODIFY COLUMN `created` datetime NOT NULL

After running that if fixed my issue. Maybe in your case you could try modifying to datetime(6) instead.

Answer 2

We had this same issue popup while pushing code from local environment (Mac OS X) up to App Engine. While altering the fields like Alexander mentioned to be DATETIME instead of DATETIME(6) did start making them appear, we lost the microseconds. Ended up realizing that in local environment we were running MySQLdb 1.2.5 but when deploying to App Engine, even though we had specified "latest" as the version of MySQLdb, it was only pulling 1.2.4b4, hard-coding to 1.2.5 fixed the issue.