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. Obviously, I didn't say user profiles were narrow; I said the benefit of having this special case is limited. > Second, I'm not sure why you're devoting so much energy to what's I'm not. I keep saying it's not a big deal, doesn't really need to be changed, and that I just wanted to know how it got that way; you keep writing essays in response. I'm going to elide the rest so I don't get another essay dropped on my head. > Personally I'm still a bit wary of OneToOneField. Not for any reason > related to the code or technical issues, but simply because of what it > implies -- OneToOneField is most useful for handling the link between > two classes in a multi-table inheritance situation (which is how > Django makes use of it internally), and any time I see a OneToOneField > my instinctive reaction is "oh, this is meant to behave like a > subclass of that other model". I find the "zero or one to one" case much more commonly useful, and OneToOneField is much more natural for that (because ForeignKey's reverse gives a set); but that's the subject of another thread (and, of course, that topic is what led me to wonder about this one). -- Glenn Maynard --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
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
> standardizing how to get to something while leaving that something
> completely undefined, so you can't actually do much of anything with
> it except stuff like auto-generated forms. It just seems like a
> narrowly useful special case.
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.
Second, I'm not sure why you're devoting so much energy to what's
basically a bikeshed argument (we painted it "get_profile()", and you
want it to be painted "profile"). Yes, it's named that way for largely
historical reasons, but to change it at this point, given our
compatibility policy, we'd need conclusive proof that it's completely
broken. Which it isn't: it works just fine, you just happen to not
like the name.
Third, as I've pointed out, basing it off AUTH_PROFILE_MODULE makes
things like determining the profile model a bit easier (to get at it
from nothing but a related name, you need to know enough undocumented
stuff to walk your way across a couple of internal-only objects).
It also avoids any confusion that might come from someone sticking an
attribute of the wrong name onto a User ('profile' can and probably
does mean "related object storing user-specific profile information",
but it doesn't necessarily mean that, and having people think you're
implementing an interface when you're not is risky), and makes it a
bit easier to work around potential namespace collisions (what happens
if you're using two apps, each of which has a model that can be used
as the profile? Under a magical-reverse-name scheme one or the other
would blow up with an accessor collision, but with AUTH_PROFILE_MODULE
you don't get forced into naming the relation a particular way and so
can avoid this problem).
> Also, it's not mutually exclusive with accessing the profile
> directly--is there any reason the docs shouldn't recommend
> OneToOneField instead of ForeignKey for the profile's user field?
> It's a better fit; this seems like a relic from before OneToOneField
> was stable.
> http://docs.djangoproject.com/en/dev/topics/auth/#storing-additional-information-about-users
Personally I'm still a bit wary of OneToOneField. Not for any reason
related to the code or technical issues, but simply because of what it
implies -- OneToOneField is most useful for handling the link between
two classes in a multi-table inheritance situation (which is how
Django makes use of it internally), and any time I see a OneToOneField
my instinctive reaction is "oh, this is meant to behave like a
subclass of that other model".
A unique ForeignKey, on the other hand, doesn't carry any such semantics.
--
"Bureaucrat Conrad, you are technically correct -- the best kind of correct."
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To post to this group, send email to django-developers@googlegroups.com
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en
-~--~~~~--~~--~--~---
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 their own helpers and such. That's why Django has a standard API > for handling user profiles. 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 something while leaving that something completely undefined, so you can't actually do much of anything with it except stuff like auto-generated forms. It just seems like a narrowly useful special case. > Well, the thing is that Django's had this API for years now, and > people are familiar with it; while I'm sure it's possible to come up > with other options which may or may not be "clearer", get_profile() > has the advantage of already being a known, standard idiom in Django, > which means people are more likely to recognize it and know what your > code is doing than if you come up with your own system. If someone can't instantly understand that "user.profile" refers to the user's profile, they're already in trouble. :) Anyhow, even if it seems like a funny special case to me, it's probably a total of twenty lines of code in auth, so it's harmless. I just wanted to know if there was some deeper design concept behind it. Also, it's not mutually exclusive with accessing the profile directly--is there any reason the docs shouldn't recommend OneToOneField instead of ForeignKey for the profile's user field? It's a better fit; this seems like a relic from before OneToOneField was stable. http://docs.djangoproject.com/en/dev/topics/auth/#storing-additional-information-about-users -- Glenn Maynard --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
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 COLUMN" > statement. > No code change for django was needed. But I have only done this once and this > application does not exist any more. > > rah schrieb: > > > I am Rahul.using Django0.96 from last 3 years. We are using > > BinInteger field in one of our models. For BigInt we have added a > > patch in Django. But now we want to migrate .96 to 1.0.2 . > > The same problem is there in 1.0.2 it does not support to BigInt > > field .The patch for 0.96 is not working with 1.0.2. Is there any > > patch for BigInt in Django 1.0.2. > > -- > Thomas Guettler,http://www.thomas-guettler.de/ > E-Mail: guettli (*) thomas-guettler + de --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
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 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. That's why Django has a standard API for handling user profiles. > It also assumes that there's just one type of profile--I'd think that > an app that wants to store information per user would want to have its > own model, since expecting the "main" user of the site to add some > boilerplate entries to his profile model doesn't seem very nice. The > reverse OneToOne mappings mostly scale to this sort of thing cleanly. It does assume only one profile model, but that's by far the common case, and so that's what's supported. More complex multi-profile situations veer off into the realm of things that can't really be supported by an API that's both simple and generic, and have such varied use-cases (e.g., how do you decide which type of user gets which type of profile? Do some users get multiple profiles? Do users move from one type to another over time?) that asking people to write their own custom code is more acceptable, since so many of those will be one-off/highly-specialized systems anyway. > I don't think "user.get_profile()" is measurably clearer than > "user.profile", though I guess it would be if you named your profile > class "Teapot". Well, the thing is that Django's had this API for years now, and people are familiar with it; while I'm sure it's possible to come up with other options which may or may not be "clearer", get_profile() has the advantage of already being a known, standard idiom in Django, which means people are more likely to recognize it and know what your code is doing than if you come up with your own system. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
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; that's mostly what I was curious about--whether get_profile() as an API predated the ORM's current relationship API and was mostly historical, since it mostly seems like duplicate functionality. > That means you can write generic code which, for example, looks up the > profile model and generates a form for it, or which provides generic > support for managing user profiles (I've written this sort of thing, > and found it both extremely easy and extremely handy). 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 also assumes that there's just one type of profile--I'd think that an app that wants to store information per user would want to have its own model, since expecting the "main" user of the site to add some boilerplate entries to his profile model doesn't seem very nice. The reverse OneToOne mappings mostly scale to this sort of thing cleanly. > Using AUTH_PROFILE_MODULE and get_profile() also helps to clarify to > other people what your code is doing: by now it's such an established > convention that people who look at your applications will immediately > understand what's going on. I don't think "user.get_profile()" is measurably clearer than "user.profile", though I guess it would be if you named your profile class "Teapot". -- Glenn Maynard --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Why does get_profile exist?
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 first couple public releases of Django, back in 2005 and 2006 -- all relationship-traversal in the ORM *was* actually done by explicit method calls. For example, if you had a weblog with an Entry model, and Entry had a foreign key to User, with the field named 'author', you'd write 'some_entry.get_author()' to retrieve the related User object. So a 'get_()' method was what you'd expect to find at the time. The reverse side of the relationship was a bit trickier. If you had a User and wanted all their blog entries, then (assuming the blog app was named 'blog'), you'd write 'some_user.get_blog_entry_list()'. In other words, the name of the application was a required part of the reverse query syntax. And that gives a clue as to why get_profile() was a useful abstraction: it required no knowledge of the name of the application in which the profile model was defined, which meant you could write more generic profile-oriented code. Django's ORM was significantly refactored for the 0.95 release (what was known as the "magic removal" effort), and relationships on models (in fact, all fields on models, but that's not relevant to this discussion) were encapsulated in descriptors, so that -- to the end 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. So get_profile() continues to exist, and to work much as it always has. Personally, I think the machinery associated with it is still fairly useful; as it stands, you can check for the AUTH_PROFILE_MODULE setting to find out 1) Whether you're running on a project that has some sort of custom user profile, and 2) If so, which model represents that profile. That means you can write generic code which, for example, looks up the profile model and generates a form for it, or which provides generic support for managing user profiles (I've written this sort of thing, and found it both extremely easy and extremely handy). In theory, some other convention for designating the profile model could be established; requiring it to have a reverse relationship with a specific name, and then doing introspection on the User model to find out what's on the other end of that relationship, would be one possibility. But doing that reliably is a bit tricky, since it requires knowledge of a couple internal APIs. Getting the appropriate profile model from the AUTH_PROFILE_MODULE setting, on the other hand, is a bit easier -- you can get at it through Django's model-loading API (which, though also technically internal, is far simpler and, at least in the part you need for this, unlikely to change) or you can get at it through the contrib.contenttypes framework. Using AUTH_PROFILE_MODULE and get_profile() also helps to clarify to other people what your code is doing: by now it's such an established convention that people who look at your applications will immediately understand what's going on. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
Re: Why does get_profile exist?
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 relationships within the community, let > alone Django itself. So, at least in part, the answer is for > historical reasons. I still see some issues with OneToOne reverse relationships. In particular, it's easy to accidentally assign to them, which doesn't work as one would expect--you have to save the model that holds the relationship to save the change, so this leads to silent faliures: obj.related = obj2 obj.save() # should be obj2.save() obj.related = obj3 obj.save() # should be obj2.save(); obj3.save() in that order obj.related = None obj.save() # should be obj3.save() I assume these are known limitations that are probably a bag of worms to fix, but the main issue I have is that it leads to obscure failures: these reverse relationships look the same as a forward relationship, so I need to carefully examine the object to see if "related" is a forward or reverse relationship whenever I assign to it. It would be useful if I could specify that I never want to be assign to a reverse relationship and an exception should be thrown--any time I'm doing that, it's probably a mistake. > See other reasons discussed elsewhere [1]. Particularly the last > section of that post. > > [1]: > http://www.b-list.org/weblog/2006/jun/06/django-tips-extending-user-model/ > It’s a completely consistent generic interface. Using the standard API in the > example above means hard-coding u.userprofile all over the place; what > happens if you later change the name of that model, or decide you need to > reuse that code somewhere else? Using the AUTH_PROFILE_MODULE setting and > get_profile() makes your code more robust and more portable. The same argument could be made for every relationship, both forward and backward, and the result would be wrapping every relationship in a function. > It makes site-specific user customization insanely easy. If you’re using > Django’s bundled ‘sites’ application to manage multiple sites which each have > their own settings files, each one can use a different custom model tailored > to its needs. If they're different models, then they presumably contain different things. I don't know what the benefit is of having a consistent method name to access inconsistent models. 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). -- Glenn Maynard --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
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 (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 relationships within the community, let alone Django itself. So, at least in part, the answer is for historical reasons. See other reasons discussed elsewhere [1]. Particularly the last section of that post. [1]: http://www.b-list.org/weblog/2006/jun/06/django-tips-extending-user-model/ -- \X/ /-\ `/ |_ /-\ |\| Waylan Limberg --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
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 can then get the user profile and > don't have to rely on the profile being called profile or whatever. Third party apps would need columns in it to use it, so apps would need to require you to manually paste fields into your profile model--which I assumed wasn't the intent. > oh, and this list is for the development of django. > Question about the usage of django should be directed at django-users. I'm well aware of both lists. This is a question about the design (development) rationale of Django. -- Glenn Maynard --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
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 ForeignKey to > OneToOne (the docs say to use ForeignKey, not OneToOne--is this an > error?) and it works fine. > > It does mean you can access the profile without knowing the name of > the class, but you need to know the contents of the model to do > anything with it anyway. Do user profiles predate reverse > relationships? I'm just curious about the the design rationale here. > oh, and this list is for the development of django. Question about the usage of django should be directed at django-users. adi --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
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 profile and don't have to rely on the profile being called profile or whatever. adi --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
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 OneToOne--is this an error?) and it works fine. It does mean you can access the profile without knowing the name of the class, but you need to know the contents of the model to do anything with it anyway. Do user profiles predate reverse relationships? I'm just curious about the the design rationale here. -- Glenn Maynard --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
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 only suggested the method I did for backwards compatibility. If you can convince people that the migration is worth it, then one migration path would be to do what I said, and then change the default to reverse_null=True for 2.0. I think the exception behavior should stay available, though, since sometimes that is what you want, and it's a nasty migration path to fully eliminate it: you'd have to audit your entire codebase to check everywhere that depends on the exception being raised for error handling, which means every place these reverse relationships are accessed at all. That's far worse than just editing all of your OneToOne declarations. On Mon, Apr 13, 2009 at 9:26 AM, Shai Berger wrote: > On Monday 13 April 2009 15:28:50 George Vilches wrote: > What I get from your description is a suggestion that: > > A) OneToOne reverse relation behavior will not change > B) FK(unique=True) will also create a reverse-relation property returning a > single object, and > C) That reverse-relation property will return None when no object is found, if > the FK is nullable Other than C, I guess one way of looking at this is: - OneToOne *really* means exactly one to one: each object on both sides of the relationship has exactly one on the other side. In this case, raising an exception is correct, but as you said, this is a relatively rare case, and the documentation should even say "OneToOne is probably not what you want". - ForeignKey means OneToZeroOrOne (perhaps "ZeroOrOneToOne" is more accurate) if unique=True. This seems a little odd: the uncommon OneToOne case gets its own relationship class, and the very common case gets tucked away in a flag. I'd suggest the "one to one (or none)" relationship type should have its own type, for the same reason OneToOne exists--it's a distinct type of relationship. I don't know what it would be called, though; "OneToZeroOrOne" is awkward. I don't think this wins anything over a flag in OneToOne, though, other than an awkward class name. -- Glenn Maynard --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
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 command works just like ``manage.py test``. > I've been working on a major refactoring recently: > http://bitbucket.org/ned/coveragepy/ . Yeah, the speed increase in coverage.py 3.x looks promising, for sure. I'm looking forward to working with it. -- George --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
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 realization of the idea that "OneToOne" relations > > are > > really, in a total majority of cases, "OneToZeroOrOne" relations. > > I've been down this road before, and have been shot down with comments > along the line of "what you really want is a ForeignKey(unique=True, > null=True)". The problem is that you can't easily follow the reverse > of that (it requires a separate query, which could get very > expensive). #7270 attempts to make that case not require an extra > query for both 121 fields and FK(unique=True), and to have > FK(unique=True) have an accessor which makes it syntactically similar > to 121. This makes little sense to me, as the documentation[1] clearly describes 121 as similar to a ForeignKey with unique=True, but the "reverse" side of the relation will directly return a single object. What you just described is, therefore, a "folding" of 121 into ForeignKey. I haven't read the patches thoroughly, but in the discussion #7270 says nothing about syntax changes, just select_related changes, and my concern here is with logic, not performance. FWIW, while perusing the ticket, I found Malcolm[2] seeming to agree with my basic analysis... though perhaps not my conclusions :-) > The current leaning for that ticket the last time I talked > with Malcolm is that the 121 portion is very likely to get accepted, > the FK(unique=True) portion is less likely. However, if you had the > FK part, would that resolve most of your issues, with the exception of > the model inheritance instances? As I said, I don't see syntax changes in #7270, so I'm not sure you're referring to the right ticket, and I'm not sure what exact set of changes you are talking about. Also, I don't think I (or anyone on this thread) asked for syntax changes, but rather for semantic changes (the behavior of the reverse- relation property). What I get from your description is a suggestion that: A) OneToOne reverse relation behavior will not change B) FK(unique=True) will also create a reverse-relation property returning a single object, and C) That reverse-relation property will return None when no object is found, if the FK is nullable If that is indeed the suggestion, then I find it lacking for two reasons: It creates a weird discrepancy between FK and 121, and it doesn't address the concern that nullability of the reverse relation is independent of nullability of the primary. Thanks, Shai. [1] http://docs.djangoproject.com/en/dev/ref/models/fields/#onetoonefield [2] http://code.djangoproject.com/ticket/7270#comment:16 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
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 > really, in a total majority of cases, "OneToZeroOrOne" relations. I've been down this road before, and have been shot down with comments along the line of "what you really want is a ForeignKey(unique=True, null=True)". The problem is that you can't easily follow the reverse of that (it requires a separate query, which could get very expensive). #7270 attempts to make that case not require an extra query for both 121 fields and FK(unique=True), and to have FK(unique=True) have an accessor which makes it syntactically similar to 121. The current leaning for that ticket the last time I talked with Malcolm is that the 121 portion is very likely to get accepted, the FK(unique=True) portion is less likely. However, if you had the FK part, would that resolve most of your issues, with the exception of the model inheritance instances? Thanks, George --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
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 wrote: > > Accessing a reverse OneToOneField mapping with no object raises > > DoesNotExist (http://code.djangoproject.com/ticket/10227). I think > > the difference between when an object is expected and when None is an > > ordinary result is strong and common enough to warrant a field option. > > > > The vast majority of the time, I want None on a reverse OneToOne > > mapping, and having to catch DoesNotExist every time is a pain. 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 really, in a total majority of cases, "OneToZeroOrOne" relations. To support this claim, think of the most common use for OneToOne relations: multi-table inheritance. In this case, the claim "the reverse relation should always find an object" translates to "every parent instance should also be an instance of _every_ child", which I find nonsensical. (well, yes, the above is taking it a bit far. what it minimally translates to is "you should never access the child through the parent without prior evidence that the parent is actually a child instance". This interpretation still makes things much more cumbersome than they need to be, suggesting type- fields on parents and similarly horrible kludges). > > Occasionally, I want to assume that the object will always exist and > > raising an exception if it doesn't is correct. > > contrib.auth.User.get_profile() is an example of a usage that probably > > actually would want an exception, if it had been implemented with > > reverse mappings. This is a very specific use-case; a hook for extension by inheritance. As get_profile demonstrates, it is probably better to use more specific mechanisms in such cases anyway. Using reverse-relations with such hooks implies all sorts of limitations on the extending code. 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. My 2 cents, Shai. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~--~~~~--~~--~--~---
