Django

Code

Ticket #3689 (closed: fixed)

Opened 1 year ago

Last modified 4 months ago

__year search trouble on 1st of january

Reported by: Dirk Datzert <dummy@habmalnefrage.de> Assigned to: nobody
Milestone: Component: Database wrapper
Version: SVN Keywords:
Cc: nesh@studio-quattro.com Triage Stage: Accepted
Has patch: 1 Needs documentation: 0
Needs tests: 1 Patch needs improvement: 1

Description

Hi,

I detected in a data_hierarchy filter a strange behavior of dates at 1.1. of a year. I have a field birthday defined as a models.DateField?(...). I'm working with a sqlite3 database, python2.5 and django-trunk.

Selecting in the admin view the year say 1990 all dates above 1.1.1990 are selected but not the 1.1.1990 himself. Maybe this was introduced by the [4505] patch!?

Regards, Dirk

Attachments

year-search.patch (0.6 kB) - added by Dirk Datzert <dummy@habmalnefrage.de> on 03/09/07 12:59:15.
this would fix my problem
sqlite.diff (1.8 kB) - added by Nebojsa Djordjevic <nesh@studio-quattro.com> on 07/31/07 13:17:04.
patch + tests
sqlite2.diff (2.1 kB) - added by Nebojsa Djordjevic <nesh@studio-quattro.com> on 07/31/07 13:20:15.
whoops, old patch
sqlite3.diff (2.4 kB) - added by Nebojsa Djordjevic <nesh@studio-quattro.com> on 07/31/07 13:34:33.
latest ;)

Change History

03/09/07 12:59:15 changed by Dirk Datzert <dummy@habmalnefrage.de>

  • attachment year-search.patch added.

this would fix my problem

03/09/07 15:13:00 changed by Dirk Datzert <dummy@habmalnefrage.de>

  • needs_better_patch changed.
  • has_patch set to 1.
  • needs_tests set to 1.
  • needs_docs changed.

(follow-up: ↓ 4 ) 03/10/07 06:01:26 changed by mtredinnick

  • needs_better_patch set to 1.
  • stage changed from Unreviewed to Accepted.

I'm pretty sure this is SQLite-specific and we've had similar bugs in the past. The problem is the SQLite does not treat "2007-01-01 00:00:00" the same as "2007-01-01" and we really need to be querying with the latter. Ticket #1460 shows the previous occurrence.

I think the change in this patch should not restrict the change just to the start date. That feels a bit asymmetrical. Shouldn't the final test also be "< (year+1)-01-01" ?

07/31/07 12:05:06 changed by Nebojsa Djordjevic <nesh@studio-quattro.com>

  • cc set to nesh@studio-quattro.com.

(in reply to: ↑ 2 ) 07/31/07 13:16:32 changed by Nebojsa Djordjevic <nesh@studio-quattro.com>

  • component changed from Admin interface to Database wrapper.

This is not just a admin problem any foo__year query is affected. I hit it today in my non-admin related code.

Replying to mtredinnick:

I think the change in this patch should not restrict the change just to the start date. That feels a bit asymmetrical. Shouldn't the final test also be "< (year+1)-01-01" ?

Here is my stab at this, patch now checks <(year+1)-01-01 and I added some tests also (in tests/regressiontests/datatypes/models.py hope that's OK)

Also, I found another place with 00:00:00 in _sqlite_date_trunc -- should we change this also?

(btw. should I change any of the triage fields after submitting patch?)

07/31/07 13:17:04 changed by Nebojsa Djordjevic <nesh@studio-quattro.com>

  • attachment sqlite.diff added.

patch + tests

07/31/07 13:20:15 changed by Nebojsa Djordjevic <nesh@studio-quattro.com>

  • attachment sqlite2.diff added.

whoops, old patch

07/31/07 13:22:48 changed by Nebojsa Djordjevic <nesh@studio-quattro.com>

Strange, now I got: 

File "/Users/nesh/Documents/workspace/django/tests/modeltests/basic/models.py", line ?, in modeltests.basic.models.__test__.API_TESTS
Failed example:
    Article.objects.filter(pub_date__year=2004)
Expected:
    []
Got:
    [<Article: Area woman programs in Python>]

Looking into it ...

07/31/07 13:33:59 changed by Nebojsa Djordjevic <nesh@studio-quattro.com>

Strange, now is OK, maybe probem was with %s-1-1??

I added some future/past checks just to be sure.

07/31/07 13:34:33 changed by Nebojsa Djordjevic <nesh@studio-quattro.com>

  • attachment sqlite3.diff added.

latest ;)

09/16/07 17:06:13 changed by ubernostrum

  • keywords set to qs-rf.

#5365 was a duplicate.

09/16/07 17:14:21 changed by ubernostrum

See also #5504 which is covering discussion of testing for these cases.

12/05/07 22:18:14 changed by ubernostrum

#6141 was a duplicate and also had some patches.

02/23/08 02:26:17 changed by mtredinnick

  • keywords deleted.

02/23/08 02:36:41 changed by mtredinnick

  • status changed from new to closed.
  • resolution set to fixed.

(In [7150]) Fixed #3689, #5223 -- Fixed "1st of January" comparisons for SQLite without breaking the other backends.

Based on a patch from raminf and tests from Nebojsa Djordjevic.

Add/Change #3689 (__year search trouble on 1st of january)




Change Properties
Action