A word of warning for the reading committer who's busy with 1.1 issues: The
following contains backwards-incompatible change suggestions, and so should
probably be left to later.
On Monday 13 April 2009 08:53:30 Elliott wrote:
> On Apr 12, 1:51 am, Glenn Maynard wrote:
> > Accessing a reverse
On Apr 13, 2009, at 5:55 AM, Shai Berger wrote:
> I think a stronger case can be made: The reverse OneToOne relation
> just should
> not throw DoesNotExist, always returning None when there is no
> matching
> object. This is a realization of the idea that "OneToOne" relations
> are
> reall
On Monday 13 April 2009 15:28:50 George Vilches wrote:
> On Apr 13, 2009, at 5:55 AM, Shai Berger wrote:
> > I think a stronger case can be made: The reverse OneToOne relation
> > just should
> > not throw DoesNotExist, always returning None when there is no
> > matching
> > object. This is a real
On 4/9/2009 7:39 PM, Ned Batchelder wrote:
> George, I'd love to hear about your changes to coverage.py.
Over the weekend I made my test coverage test runner into a third party
app. So you just have to install the app, add some settings, and run
``manage.py test_coverage [app1 app2 ...]``. The co
On Mon, Apr 13, 2009 at 9:26 AM, Shai Berger wrote:
> As mentioned above, I realize what I'm advocating here is a backwards-
> incompatible change; what I hope to achieve is agreement that this should be
> the correct behavior, and then a migration path towards it.
I agree; I only suggested the
Why do get_profile() and AUTH_PROFILE_MODULE exist, instead of just
declaring the Profile to User relationship as OneToOne and using the
auto-generated User.profile relationship?
I just changed my Profile's User relationship from ForeignKey to
OneToOne (the docs say to use ForeignKey, not OneToOn
On 13.04.2009, at 22:30, Glenn Maynard wrote:
>
> Why do get_profile() and AUTH_PROFILE_MODULE exist, instead of just
> declaring the Profile to User relationship as OneToOne and using the
> auto-generated User.profile relationship?
Probably because third party apps can then get the user profil
Hi,
On 13.04.2009, at 22:30, Glenn Maynard wrote:
>
> Why do get_profile() and AUTH_PROFILE_MODULE exist, instead of just
> declaring the Profile to User relationship as OneToOne and using the
> auto-generated User.profile relationship?
>
> I just changed my Profile's User relationship from Fore
On Mon, Apr 13, 2009 at 4:50 PM, Adi Sieker wrote:
>> Why do get_profile() and AUTH_PROFILE_MODULE exist, instead of just
>> declaring the Profile to User relationship as OneToOne and using the
>> auto-generated User.profile relationship?
>
> Probably because third party apps can then get the use
On Mon, Apr 13, 2009 at 4:30 PM, Glenn Maynard wrote:
>
> Why do get_profile() and AUTH_PROFILE_MODULE exist, instead of just
> declaring the Profile to User relationship as OneToOne and using the
> auto-generated User.profile relationship?
>
Well, prior to qs-refactor (just before 1.0), OneToOn
On Mon, Apr 13, 2009 at 6:01 PM, Waylan Limberg wrote:
> Well, prior to qs-refactor (just before 1.0), OneToOnes had some
> issues and the documentation included very strong warnings that they
> should not be used at all. That being the case, as that time you found
> almost no use of OneToOne rel
On Mon, Apr 13, 2009 at 6:12 PM, Glenn Maynard wrote:
> Anyhow, I'm not advocating changing it--nothing prevents people from
> ignoring get_profile entirely and just using OneToOne (which is
> probably what I'll do).
Well.
First let's explore why get_profile() exists. Back in the day -- the
fir
On Mon, Apr 13, 2009 at 8:02 PM, James Bennett wrote:
> user -- they behaved more like normal attributes. At that point
> get_profile() could have been refactored into a read-only property,
> but there really weren't any pressing API-design reasons for doing so.
Sure; that's mostly what I was cu
On Mon, Apr 13, 2009 at 7:32 PM, Glenn Maynard wrote:
> Well, you might want to do that for any model, and the admin API
> provides a more generic approach to managing this sort of task--but
> OK.
It's true you *might* want to do it for any particular model, but the
specific case of user profile
You could even put such an `ALTER TABLE` statement in a `sql/
modelname.sql` file to be executed as initial SQL data as soon as the
table is created by `syncdb`.
On Apr 8, 11:40 pm, Thomas Guettler wrote:
> Hi,
>
> I once get BigInt working by a little "ALTER TABLE ... ALTER COLUMN"
> statemen
On Mon, Apr 13, 2009 at 8:55 PM, James Bennett wrote:
> It's true you *might* want to do it for any particular model, but the
> specific case of user profiles is such a common situation that it
> seems a shame to require everybody to come up with their own system
> and their own helpers and such.
On Mon, Apr 13, 2009 at 8:34 PM, Glenn Maynard wrote:
> You don't need to come up with helpers--OneToOneField automatically
> creates the only helper this provides, in a way that (unlike
> get_profile()) is consistent with all other model relationships. It's
> standardizing how to get to somethi
On Tue, Apr 14, 2009 at 12:00 AM, James Bennett wrote:
> Well, first of all user profiles aren't a "narrowly useful special
> case" -- they're an extremely common feature needed on lots of
> real-world sites. So having some sort of standard API for that is a
> good thing.
Obviously, I didn't say
18 matches
Mail list logo