On 4/4/07, Max Derkachev <[EMAIL PROTECTED]> wrote: > Well, User do nothing with the profile other then simply loading it in > get_profile.
Except that 'get_profile' uses a Django database API lookup. Suppose we remove that, though: 1. How do we know what sort of object the "profile" is? 2. How do we figure out how to retrieve it? 3. If it's an instance of a class, how do we figure out which instance to retrieve? Right now those questions are easily answered: 1. It's a Django model. 2. We use the Django database API. 3. We look for a relation back to the User object and filter on that. > Django Model persistence does not cover all the use cases. Now I use > two persistence strategies in my application apart from the django > models, and I've managed to make all of them cooperate nicely. But now > I'm forced to hack get_profile to make it work with my custom user > profile that use a different persistence strategy, simply because > get_profile blindly insist on Model-based profiles. I think that any time you're mixing and matching two object persistence layers and trying to tie objects from one to objects from the other, it should be expected that there's going to be a little bit of work involved in making that happen -- if every persistence system had to "know" and take into account the possibility of being related to arbitrary objects from every other persistence system, the "generic" code to support all that could get very nasty indeed. -- "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 -~----------~----~----~----~------~----~------~--~---
