On Wed, Mar 21, 2012 at 1:48 AM, Russell Keith-Magee < russ...@keith-magee.com> wrote:
I agree - that's why my original proposal was to make the LazyForeignKey > explicit -- that makes the adoption process opt in. Yes, this means that > apps need to be modified and advertised to be "1.5 > swappable-User-compliant". However, to my mind, that's a good thing, > because you have an explicit marker that the author of the app expects the > app to work with an User model, or that they've documented any specific > requirements that the app needs to see in a swappable User object. > I appreciate the appeal of explicitly stating LFKs, I'm just concerned about the timeframe. Let's say we work through the design issues and have working LFK code available for 1.4.1. Based on your past experience, how long do you think it would take for, say, the 50 most common django apps (with FKs to User) to adapt? An unstated constraint that guided my pluggable auth apps design was the desire to ship something that makes email authentication possible in 1.4.1. I'm solution-agnostic, though, and if you think we could have LFKs ready and a healthy cross-section of apps ported by the 1.4.1 release, then I'm fully behind that idea. But if it will take longer than a year or so, then I am more inclined to look for an alternative solution that gets us there faster. This is also an area where test suites can help -- if an app has any > special expectations for User, the app author can write tests that > specifically check those integration requirements. > Agreed: apps should trust (that the developer read the requirements), but verify (with tests). I'm not sure I see why using a pluggable auth app instead of an auth model > changes anything. A third party app still needs to have foreign keys to a > model that might not meet contractual expectations. It could define > ModelForms that have clean methods or widget overrides for fields that > don't exist, or define redundant fields. You could define a model subclass > that has fields that clash with the base class. AFAICT, the problems that > exist are with being swappable in general, not with the requirements of > User (or auth) itself. > That's entirely true. The motivation for making several components of django.contrib.auth pluggable was, again, to do something backwards compatible that allows for at least some basic modification of the User model on a time scale that approaches "soon". > It would be folly to assume that every app with a User dependency will > seamlessly adapt to any swappable User model. Duck typing is useful, but it > isn't magical -- at some point, the responsibility needs to fall with the > app developers to document the species of duck they need, and for project > developers to check that they duck they have is appropriate for the task. > I agree, and noted in the previous thread that the burden for ensuring that the new User model works with third-party apps falls on the author of that User model. I assume, perhaps naively, that pluggable auth apps would be used sparingly, by advanced users with specific requirements that can't be met with the existing User model. I assume also that most changes would be relatively minor: dropping the username field, or "fixing" the email field (where the developer gets to define what that means), but not, say, removing all of the authorization attributes required by the admin. > [2] — Inheriting from a "swappable" model (auth.User isn't a very > realistic example here) > > ... > > Granted, I don't see many real-world use cases for this, but I suppose > somebody might want to have a pluggable model *and* subclasses thereof. > > I'm not sure I see any use cases either -- and even if I could, I'm not > sure this would be solved elegantly. At least for the first iteration, I'd > be inlined to punt the issue, and just say swappable models can't be base > classes, and enforce that at a class instantiation level. > That's a reasonable stipulation, I think. To be clear on the ModelForm issue, though, is it correct to say that any LFK proposal must also provide LMFs (Lazy ModelForms)? Cheers, Clay -- 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.
