Hello! The page you linked<https://code.djangoproject.com/wiki/ContribAuthImprovements>, Tom, concludes with this line: "Discussion on django-developers suggests that complete consensus is unlikely; Currently awaiting BDFL mandate."
Since we have the BDFL mandate, shouldn't we update the page? Best regards, Max On Tue, Apr 10, 2012 at 10:58 AM, Tom Evans <tevans...@googlemail.com>wrote: > On Tue, Apr 10, 2012 at 3:13 PM, Ian Lewis <ianmle...@gmail.com> wrote: > > Hi, > > > > I'm not getting why you *have* to add fields to the User model to store > data > > pertaining to the user. There is nothing in the proposal for pluggable > user > > models that says you can never have a seperate model with a foreign key > to > > the user model. It just means that you can define your user model the way > > you want it to be. > > That is perfectly fine. The problem comes when there is a simple > system to add fields to the user model, people will use it to add > fields to the user model in their pluggable apps, for 'simplicity' and > 'ease of use'. > > > Why can't third party apps have a model with a foreign key to the user > table > > with the pluggable models approach? I imagine you are right that every > app > > and it's brother adding fields to the user model is not realistic but I > > don't think that anyone has proposed that. Certainly not me. > > The proposed solution as decided by BDFL diktat is 2a from [1]. I quote: > > Split off as much as possible of auth.User into orthogonal mixins that > can be reused. > Modify auth.User to inherit these mixins. Care must be taken to ensure > that the database expression of the new User model is identical to the > old User model, to ensure backwards compatibility. > Unrelated and third-party apps can indicate that they depend on > various orthogonal mixins. For example, contrib.admin can specify that > it works with auth.User out of the box, and with any model > implementing PermissionsMixin if you supply your own login forms. > > At the moment, you cannot change the user model, so we do not have > issues relating to third party apps changing the user model. With the > proposed solution, you would be able to change the user model, so we > may have issues. > > It's also enlightening to read the code from Alex's Django branch, > which is an initial implementation of option 2a. > > > The thing I > > want to be able to is define user models suitable for my project. Third > > party apps adding their own fields wasn't proposed by anyone AFAIK, nor > was > > specifically requiring that you add them yourself. Some might require > that > > your user has something like an 'email' field because that would be a > common > > field across apps but app specific data can easily go on a seperate model > > included with the app that simply has a FK to user. You can then only > fetch > > that data on requests that need it. > > > > I'm sorry but doing a JOIN every request is a BAD idea. You will run into > > problems there quickly and have no way out of it besides ditching auth > > completely (and thus all the thirdparty apps you use that depend on it). > > I completely disagree, but I'm not here to try and convince people how > to design their databases. A JOIN every request will not end the > world. Besides, it is far more likely to be a separate query than a > JOIN, and would only happen on views that required that data. > > More to the point, what basis are you making this claim on? People > love to pipe up "JOINs are slow and evil", but have you actually > analysed the cost compared to monolithic tables? > > > Assuming the user table and profile tables are small is awfully short > > sighted. > > To be fair, I was slightly ambiguous with my use of the word 'small'. I > said: > > >> Queries against monolithic tables are much slower than a few queries on > much > >> smaller tables. > > Here 'small' means fewer columns, not less tuples. > > However, assuming tables will be small is precisely what you have just > done - "we must not have JOINs, they are evil, but it doesn't matter > because the user table will only have the columns I desire". I agree > that it is a short sighted position, if you do not prevent the table > becoming monolithic ;) > > > Cheers > > Tom > > [1] https://code.djangoproject.com/wiki/ContribAuthImprovements > > -- > 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. > > -- 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.
