After discussing this on IRC, I decided that this idea could be
worthwhile, but I thought I'd post it here before creating a ticket
for it.
Disclaimer: I am using version 1.0, so I can't say whether the
behavior I observed is exactly the same in the dev version. Since
nobody told me that anything
It looks like the last discussion on this was back in Apr 2010, and
the last trunk-merge was 4 months ago. The last comment on #3591 by
russelm was that the GSOC branch "is looking reasonably good".So,
my question is, is there still any interest in getting this merged
into trunk, or is there
Thanks legutierr for all your work on this ticket and patch, and
everyone for the comments. I just took some time to review the patch
on #15089 and had a long conversation on IRC with legutierr, and
here's what I'm thinking:
It does appear that there is some code (CurrentSiteManager, for
instance)
Models with a BooleanField are instantiated with that field's value
set to False if no default or initial value is provided. Instead, like
most other fields, the field's initial value should be set to None.
This None should be left uncoerced when attempting to save the
instance, so attempting to sa
I haven't been tracking it closely, but last I heard on the subject is that
it's on target for the 1.4 release cycle. So basically once we get 1.3
pushed out (and have a little rest) that'll be towards the top of the heap
to be wrapped up and worked into trunk. There's almost certainly still som
On Wednesday, January 19, 2011 12:01:57 PM UTC-8, Carl Meyer wrote:
>
> Contrib.flatpages is an example
> of this -- the flatpage model has an FK to Site, so it doesn't make
> sense for flatpages to call a method which might return a Site object
> or might return something else. It needs a real
If you try this in any of the more recent versions (sorry I don't know
exactly when this was changed) you'll get a ViewDoesNotExist exception
telling you which view in which module it couldn't find. If you have DEBUG =
True you'll get a nice Django 500 error debug page giving you everything you
Hi Gabriel,
On Jan 19, 5:55 pm, Gabriel Hurley wrote:
> > In my mind, the introduction of a multitenancy hook (in the 1.4
> > timeframe) could then look something like this:
>
> Also agreed on the 1.4 timeframe. While there is a valid concern for making
> sure that get_current_site() (introduced
Carl and I had a long discussion in IRC about all the issues he raises
above. I am still digesting that conversation, but there are some
things that already spring to mind.
1. I can see the merits of defining a SITE_BACKEND api that would
allow users to choose from different site-retrieval implem
This seems right to me. Does anyone with more history on BooleanField
know of any reason why the "wontfix" resolution on #2855 was incorrect
and the current default-to-False behavior is correct?
Carl
--
You received this message because you are subscribed to the Google Groups
"Django developers
10 matches
Mail list logo
