Opened 8 years ago

Closed 8 years ago

#24930 closed New feature (wontfix)

Add generic archive views for objects with DateRangeFields

Reported by: Bence Nagy Owned by: nobody
Component: Generic views Version: dev
Severity: Normal Keywords:
Cc: Triage Stage: Unreviewed
Has patch: no Needs documentation: no
Needs tests: no Patch needs improvement: no
Easy pickings: no UI/UX: no


Currently Django has generic views such as MonthArchiveView for rendering a list of objects with a date field's value falling within a given timeframe.

Generic views such as this would be rather useful for objects whose place in time is determined with a date range, instead of a single date, such as subscription invoices specifying the dates covered, or multiple day events (say, a set of conferences).

Change History (4)

comment:1 Changed 8 years ago by Bence Nagy

Summary: Generic archive views for objects with DateRangeFieldsAdd generic archive views for objects with DateRangeFields

comment:2 Changed 8 years ago by Tim Graham

Marc, what's your opinion about adding generic views to contrib.postgres?

comment:3 Changed 8 years ago by Bence Nagy

Version: 1.8master

comment:4 Changed 8 years ago by Marc Tamlyn

Resolution: wontfix
Status: newclosed

The behaviour of this would have several possible options, and I don't think it's a generic enough use case to deserve Django maintaining it. What happens when the range spans two months/years? Does it appear in both? Only one? If one based on what, start? end?

As a side note, I *think*, though I'm not completely sure, that the existing archive views can be used in the "only one" case by:

  • Setting date_field = 'range__start'
  • Overriding uses_datetimefield if you are using a DateTimeRangeField
  • Overriding ordering until such a time as transforms are supported in order by clauses (hopefully forthcoming).

For the "overlaps" case, a lot more work would be needed. At present the implementation of the archive views assumes a fixed point in time, and that every object would appear in only one view. For example, getting the list of possible sub views (month views for a year) which are non empty is a much harder process.

So, one possible use case is (nearly) covered by the built in view. The second is largely different, but could definitely live in a third party package. I'd rather keep contrib.postgres for database things and their form fields rather than adding any possible related concept.

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