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.
