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).
--
Ticket URL: <https://code.djangoproject.com/ticket/24930>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
* needs_better_patch: => 0
* needs_docs: => 0
* needs_tests: => 0
--
Ticket URL: <https://code.djangoproject.com/ticket/24930#comment:1>
Comment (by timgraham):
Marc, what's your opinion about adding generic views to
`contrib.postgres`?
--
Ticket URL: <https://code.djangoproject.com/ticket/24930#comment:2>
* version: 1.8 => master
--
Ticket URL: <https://code.djangoproject.com/ticket/24930#comment:3>
* status: new => closed
* resolution: => wontfix
Comment:
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.
--
Ticket URL: <https://code.djangoproject.com/ticket/24930#comment:4>