On Mon, Apr 13, 2009 at 6:12 PM, Glenn Maynard <[email protected]> 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_<something>()' 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 [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
