Opened 13 years ago

Closed 13 years ago

Last modified 12 years ago

#306 closed defect (fixed)

cached date time values have greater precision then ones retrieved from db causing issues

Reported by: scanner@… Owned by: Adrian Holovaty
Component: Database layer (models, ORM) Version: 1.0
Severity: normal Keywords: datetime precision
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: UI/UX:

Description (last modified by Adrian Holovaty)

A problem with dates in objects in memory vs ones being instantiated
out of the database.

I have a data model for a "music root" that is a directory and two
datetime stamps, like so:

class MusicRoot(meta.Model):
    fields = (
        meta.CharField('directory', maxlength = 1024),
        meta.DateTimeField('last_scan_started', blank = True, null = True),
        meta.DateTimeField('last_scan_finished', blank = True, null = True),

I also have a track model that has some fields and a "last_scanner"
date time field, like so:

class Track(meta.Model):
    fields = (
        meta.CharField('title', maxlength = 512),
	... ...
        meta.DateTimeField('last_scanned', blank = True, null = True),

Now, in order to figure out if a "track" file has been removed (and
thus the object should be deleted) I set "last_scan_started" on the
music root to be

Then I walk the directory finding all files that are "tracks."
When I find a track I always update the track.last_scanned field with

After I am done walking all the files I do this simple operation to
find out which tracks are no longer in this music root:

        missing_tracks = tracks.get_list(last_scanned__lt = music_root.last_scan_started)

Now, earlier in the same function I had done:

        music_root.last_scan_started =

The problem? "missing_tracks" is _all the tracks_ in the music root.
Pounded my head for a couple of minutes and then realized this:

music_root.last_scan_started -> 2005-08-10 23:38:49.031080

Almost all the tracks, that were filled in via fetches from the db if
they were not cached (because where I had created the 'track' object
was in a sub-scope) were:

track.last_scanned -> 2005-08-10 23:38:49


2005-08-10 23:38:49 < 2005-08-10 23:38:49.031080

I worked around this by doing a:

music_root = musicroots.get_object(pk =

which seems to work although it might not if any funky caching is

But I should not need to do that.

Change History (5)

comment:1 Changed 13 years ago by Adrian Holovaty

Description: modified (diff)

(Changed formatting in description)

comment:2 Changed 13 years ago by Adrian Holovaty

Interesting. The problem appears to be that the milliseconds are being purged at some point.

comment:3 Changed 13 years ago by Adrian Holovaty

(In [487]) Changed timestamp and time typecasting to preserve microseconds. Added unit tests to test this behavior, and added a db_typecast unit test module. Refs #306.

comment:4 Changed 13 years ago by Adrian Holovaty

Resolution: fixed
Status: newclosed

I believe I've fixed this problem in [487]. Please update your Django code, give it another shot, and let us know whether it works properly now.

comment:5 Changed 13 years ago by scanner@…

I updated my Django code, removed the hack to work around the problem and things do indeed seem to work properly. Thank you!

Note: See TracTickets for help on using tickets.
Back to Top