Broken?

[Kevin O'Gorman]

I've got a working site, but I made a copy of the database in order to do some development work.

I've hit a snag that looks like a problem in the data.

The odd part is that this database is in production, and my backups have the same problem.  So I'm presuming my new code is broken in some way I don't understand.

For instance, Ive written a management command to show the problem:

from django.core.management.base import BaseCommand, CommandError

from oil.models import Packet, Signature, Log, Voter

class Command(BaseCommand):
    help = 'Quick test'
    BaseCommand.requires_migrations_checks = True


    def handle(self, *args, **options):
        voters = Log.objects.all()
        self.stdout.write(repr(voters[0]))

I'm suspecting a problem has crept into my Log table, because it works fine if I change Log on the

second line of handle() to any of the other tables.  If it runs as shown here however, I get

kevin@camelot-x:/build/comprosloco$ manage oiltest
Traceback (most recent call last):
  File "./manage", line 22, in <module>
    execute_from_command_line(sys.argv)
  File "/build/django/django/core/management/__init__.py", line 364, in execute_from_command_line
    utility.execute()
  File "/build/django/django/core/management/__init__.py", line 356, in execute
    self.fetch_command(subcommand).run_from_argv(self.argv)
  File "/build/django/django/core/management/base.py", line 283, in run_from_argv
    self.execute(*args, **cmd_options)
  File "/build/django/django/core/management/base.py", line 330, in execute
    output = self.handle(*args, **options)
  File "/raid3/build/comprosloco/oil/management/commands/oiltest.py", line 15, in handle
    self.stdout.write(repr(voters[0]))
  File "/build/django/django/db/models/base.py", line 590, in __repr__
    u = six.text_type(self)
  File "/raid3/build/comprosloco/oil/models.py", line 172, in __str__
    self.accepted
TypeError: sequence item 0: expected str instance, datetime.datetime found
kevin@camelot-x:/build/comprosloco$

And I have no idea how to debug it further.  The schema of Log is
sqlite> .schema oil_log
CREATE TABLE "oil_log" ("id" integer NOT NULL PRIMARY KEY AUTOINCREMENT, "packet" integer NOT NULL, "signature" integer NOT NULL, "action" varchar(20) NOT NULL, "criteria" varchar(150) NOT NULL, "candidates" varchar(100) NOT NULL, "accepted" varchar(10) NOT NULL, "user_id" integer NOT NULL REFERENCES "auth_user" ("id"), "timestamp" datetime NOT NULL);
CREATE INDEX "oil_log_packet_ecd59bc4" ON "oil_log" ("packet");
CREATE INDEX "oil_log_user_id_7f26e501" ON "oil_log" ("user_id");
sqlite>

Help???

[Jason]

Basically, its saying that something is expecting a string, but is instead getting a datetime object.  Sounds like something changed in your `oils/models.py` file

[Kevin O'Gorman]

Maybe, but while the log file has undergone some migrations in the past, it has not been much, not recently, and everything is up-to-date now.  'manage makemigrations' detects nothing.

So the question is how I can explore this.

++ kevin

[Kevin O'Gorman]

So I modified the command so that it brought out all the fields, adding them one by one in a .values() call added to the QuerySet.  They all came out just fine, every single one, including the timestamp.

As a result, I'm thinking this may be a bug in Django when it is just being called on to produce QuerySet[0] and it contains a timestamp.  Or maybe the bug depends on some other trigger.  I'm at a crucial point in the use of this code, have a workaround, so I won't do anything more with it until after our end date this coming Tuesday.  After that I'll decompress for a day or so.  Maybe then I'll produce example code complete with test data.  But I'd have to say the command is about as simple as it's gonna get.

[George Lubaretsi]

File "/raid3/build/comprosloco/oil/models.py", line 172, in __str__
self.accepted

What is inside this __str__ method? `self.accepted` field name sounds like it could be a date. Return type of __str__ must be a string.

[Kevin O'Gorman]

It is indeed a string.  The string happens to represent an integer, a key of an item in another table.  It is not an external reference because there are dated versions of the table and the referent may or may not exist in any one of them.  It existed in the table in use at the time the record was created and needs to be preserved.