#306 closed defect (fixed)
cached date time values have greater precision then ones retrieved from db causing issues
Reported by: | 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: | no | UI/UX: | no |
Description (last modified by )
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 datetime.datetime.now().
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
datetime.datetime.now().
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 = datetime.datetime.now() music_root.save()
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
so:
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 = music_root.id)
which seems to work although it might not if any funky caching is
happening.
But I should not need to do that.
Change History (5)
comment:1 by , 19 years ago
Description: | modified (diff) |
---|
comment:2 by , 19 years ago
Interesting. The problem appears to be that the milliseconds are being purged at some point.
comment:3 by , 19 years ago
comment:4 by , 19 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
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 by , 19 years ago
I updated my Django code, removed the hack to work around the problem and things do indeed seem to work properly. Thank you!
(Changed formatting in description)