I'm personally a bit "meh" on this idea, although I can see it's useful
for some number of people > 1. There's no such thing as a "simple
change". I suspect the pros and cons pretty nicely balance each other
I've been thinking through, with a couple of different people, how we
can support extra lookup types on fields and so I'm going to reserve
judgement on this particular implementation until I have some thoughts
in order on the latter subject. Maybe you'll convince another maintainer
in the interim, but it's probably a good start to get the patch up to
date and then drop it into the 1.1 features list, since running, tested
code is always a good start for assessing something.
> Any thoughts on this? The only real alternative is to drop to raw SQL
> in a calendar app - but if we can exploit functionality within the
> database to do it cleanly in the ORM, why not?
> The only potential pitfall I'm aware of is with weeks starting on
> different days, see ticket #1061 . I'm not intimate with the
> details of that ticket so can't really comment on it at this stage.
If you're writing an API for talking to the data storage layer, pick a
value for the first day that is consistent at the Django level. People
handling localised dates with different start dates will have to do the
conversion before making it a filter. When Django adds support for that
kind of stuff, we might well end up with some utility functions if this
type of filter goes into the ORM. Don't create extra problems for
yourself here by inentionally letting presentation information leak into
the ORM layer.
In my opinion this patch doesn't make any difference for any new
architecture of lookup types because it doesn't change the current one.
It just adds another item to a fixed list of supported lookup types and
several conditions leaving them as uniform as they are.