Description

Ideally default behaviour should correlate with the assumptions of the majority. Although it is clearly documented otherwise, I suspect that most people (like me :) will assume that the list_detail generic view handles an empty list exactly as it handles a populated list. I was surprised at getting 404s after reseting my database. Current bahviour has the potential to facilitate unnoticed bugs. I suggest defaulting 'allow_empty' to True. Of course this must be weighed against the hassle of backwards incompatibility and I suspect it may lose out on these grounds, but I thought it was worth ticketing for consideration.

Change History (30)

I agree. I've already come across lots of scenarios where I have got it wrong and could easily get in wrong in the future and not notice. If you've already populated one item or more in the table you don't notice the behaviour with no items. When you later add searching facilities to the list, and someone enters a search with no results, they suddenly get a 404 error. The current behaviour is unintuitive, and is simply a shortcut for a common pattern that some apps might have, but as such it shouldn't be the default.

I'm glad this came back up. I can see this "feature" catching out newbies (and some oldbies) again and again. As the fix is backwards incompatible it should really be done before 1.0 -> Priority nudge.

I'm not convinced this is "ready for checkin", since it breaks backwards compatibility. Four or five commenters in a ticket does not make a vast majority. At a minimum, I think this should wait until post-0.96 and be part of the backwards compatible changes for 1.0 if we include it.

I'm probably +1 on including the patch, but I know there is code out there relying on the current behaviour (I've written more than a few lines of such code) and breaking existing sites is not cool. So I'm moving this back to "design decision needed" in order to at least hold it over until the forthcoming release prior to the 1.0 push. Then we can decide (along with a bunch of other small items) whether we want to break backwards-compat.

I strongly agree that the default ought to be allow_empty=True, so make that five or six commenters ;)

I won't bother reiterating the arguments already made, but I will point out that if possible it'd be nice if this particular default setting was highlighted more strongly in the documentation or an FAQ. It's definitely a FAQ in the literal sense, as in I see it asked all the time.

I just got bit by this issue. If it helps, generic views allows_empty brought me to this page wishing that this change is made. I troubleshot almost everything else about my config before I tracked this down.

Will everybody please stop posting "me too" comments; it's adds no value to the ticket report, since a few extra comments in a userbase of many thousands does not change the weighting. As mentioned above, this is one of the backwards incompatibility changes we will have after 0.96 is released in preparation for 1.0. Not before 0.96.

Backward compatibility can easily be maintained as follows: change the default value of allow_empty in the view definitions to a setting e.g. DEFAULT_ALLOW_EMPTY. This can be set to False by default in settings.py, and people who want to can change the setting to True on a per-instance basis. Doesn't this let us have our cake and eat it too?