#8424 closed New feature (fixed)
Implement time filters
| Reported by: | Vincent Foley | Owned by: | Ulrich Petri |
|---|---|---|---|
| Component: | Database layer (models, ORM) | Version: | |
| Severity: | Normal | Keywords: | datetime filter hour minute second |
| Cc: | davidgrant@…, tn@…, renatopedigoni@…, john@…, aurelio@…, dougal85@… | Triage Stage: | Accepted |
| Has patch: | yes | Needs documentation: | no |
| Needs tests: | yes | Patch needs improvement: | yes |
| Easy pickings: | no | UI/UX: | no |
Description
As of r8442, it is possible to filter a queryset by year, month or day using the usual syntax,
However, filters for hours, minutes and seconds were missing. I have added those into a patch for your consideration along with unit tests and documentation.
Meeting.objects.filter(meeting_time__hour=12)
Attachments (2)
Change History (24)
by , 17 years ago
| Attachment: | time_filters.diff added |
|---|
comment:1 by , 17 years ago
comment:2 by , 17 years ago
| milestone: | → post-1.0 |
|---|---|
| Triage Stage: | Unreviewed → Design decision needed |
comment:3 by , 17 years ago
| milestone: | post-1.0 → 1.0 maybe |
|---|
I can understand why this patch as been scheduled for post-1.0, to respect the API freeze, but it should really be included in the 1.0 release.
Being able to filter by time is not a trivial or candy feature, it *should* be possible, we don't use dateTIME fields just for the fun of it.
Furthermore, in pre-1.0-beta was possible to "hack" a time filter like this:
@register.filter
def filter_by_hour(obj, time):
return obj.filter(start_time__contains=' %02d' % time.hour)
Since the beta is out (I don't know the exact revision sorry), it can't be done. It looks like a problem with the database wrapper.. I don't know if it's intentional or not.
Anyway, unless someone can point me out another easy way to filter a datetime field by time, I think this patch is primordial.
Regards
comment:4 by , 17 years ago
| milestone: | 1.0 maybe → post-1.0 |
|---|
Feature freeze has passed. This isn't a bug. It's an enhancement request.
comment:7 by , 17 years ago
| Cc: | added |
|---|
comment:8 by , 16 years ago
| Needs tests: | set |
|---|---|
| Patch needs improvement: | set |
| Triage Stage: | Design decision needed → Accepted |
| Version: | SVN |
I've needed these more than once. I can't see any reason to not have them.
Patch needs to be updated; also needs some real tests. Three queries that return nothing doesn't constitute at test of anything.
comment:9 by , 15 years ago
| Owner: | changed from to |
|---|
(djangocon.eu 2010 sprint)
I'll give this one a shot
comment:10 by , 15 years ago
| Cc: | added |
|---|
comment:11 by , 15 years ago
| Cc: | added |
|---|
comment:12 by , 15 years ago
I've added an updated patch with more tests (and I'll happily add more if needed).
P.S: Patch is in git diff format.
comment:13 by , 15 years ago
Last thunk of latest patch
--- a/tests/regressiontests/null_queries/tests.py
+++ b/tests/regressiontests/null_queries/tests.py
@@ -53,17 +53,17 @@ class NullQueriesTests(TestCase):
"""
obj = OuterA.objects.create()
self.assertQuerysetEqual(
- OuterA.objects.filter(inner__second=None),
+ OuterA.objects.filter(inner__secondary=None),
['<OuterA: OuterA object>']
)
self.assertQuerysetEqual(
- OuterA.objects.filter(inner__second__data=None),
+ OuterA.objects.filter(inner__secondary__data=None),
['<OuterA: OuterA object>']
)
inner_obj = Inner.objects.create(first=obj)
self.assertQuerysetEqual(
- Inner.objects.filter(first__inner__second=None),
+ Inner.objects.filter(first__inner__secondary=None),
['<Inner: Inner object>']
)
reveals something potentially dangerous. FTR, from a django-dev IRC channel discussion about it:
cramm: hrm, looking at the patch for #8424. cramm: Specifically the last thunk. Adding new filtering lookups like 'hour', 'second', ... means there could be clashes with existing identically named model fields? cramm: I mean, in user apps Alex_Gaynor cramm: yeah, it would Alex_Gaynor: I'd much rather wait for us to have a real solution to alternate filtering, but that won't be 1.4 at the earliest carljm: cramm, Alex_Gaynor: dunno, I'm inclined to think these are obvious omissions. carljm: i.e. "wait till we have custom filtering" doesn't make sense to me. Alex_Gaynor: carljm: unless it breaks everyone's fields named hour, second, minute carljm: yes. that, of course, is icky. carljm: that shouldn't be a problem, though. can't the splitter be smarter? carljm: i.e. only DateTimeFields can have these lookups carljm: and only related fields can be traversed. carljm: you can't traverse across a DateTimeField to a related object. Alex_Gaynor: carljm: it could, ATM it's not carljm: right. so it's a "patch needs improvement" situation, then.
comment:14 by , 15 years ago
Docs in the patch: "This will match every record with a pub_date that occurred between 3:00 AM and 3:59 AM."
3:59:15 AM is not between 3:00 AM and 3:59 AM but it should be matched.
comment:15 by , 15 years ago
| Cc: | added |
|---|
comment:16 by , 15 years ago
| Cc: | added |
|---|
comment:17 by , 15 years ago
| Severity: | → Normal |
|---|---|
| Type: | → New feature |
comment:18 by , 15 years ago
| Cc: | added |
|---|---|
| Easy pickings: | unset |
comment:21 by , 13 years ago
| Resolution: | → fixed |
|---|---|
| Status: | new → closed |
Fixed in e74e207cce54802f897adcb42149440ee154821e.
Duplicate of #8423 other closed.