Re: Why does get_profile exist?

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.

Re: Why does get_profile exist?

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 >

Re: Why does get_profile exist?

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

Re: BigInt Patch for Django 1.0.2

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

Re: Why does get_profile exist?

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

Re: Why does get_profile exist?

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;

Re: Why does get_profile exist?

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

Re: Why does get_profile exist?

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

Re: Why does get_profile exist?

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

Re: Why does get_profile exist?

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

Why does get_profile exist?

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

Re: Reverse mappings raising exceptions

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

Re: Test integration with coverage

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

Re: Reverse mappings raising exceptions

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

Re: Reverse mappings raising exceptions

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 >

Re: Reverse mappings raising exceptions

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