On Tue, Apr 10, 2012 at 11:58 PM, 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'. > Um. yeah. that's kind of the point. Third party apps being able to do so is not good but me being able to do so is really really great. No proposal that I've seen allows third party apps to add fields willy-nilly so what is the problem here? > > > 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. > Yes. Third party apps changing the user model is bad. I agree. You should need to explicitly add any field the third party app needs. Preferably these would be common things like 'email' or the user's name. Any other app specific data would go in models provided by the app with an FK to user. In other words, an app providing a user model mixin that YOU add to your user model is OK, though probably bad design. For third party app related data, it makes sense to have it in a separate table. I imagined that that mixins would be there so that you could choose to add or not add the fields to support the admin, but apps providing mixins to add fields to the user as a normal design is probably a bad idea. I see where I may have been confused. It's also enlightening to read the code from Alex's Django branch, > which is an initial implementation of option 2a. > I haven't seen that so I can't comment. > > 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? > I'm assuming that you will not have a monolithic table with 100s of columns because that would be silly but I can see now that developers of third party apps might think that's the way to add user specific data. Like I said, I think that having fields added to the user model by third party apps etc. is dumb but I never understood that anyone thought that is the solution. However, I still think JOINS across however many profiles tables being done automatically on every request is a bad idea. That data should only be retrieved for views when it is needed. In the profiles solution you would *HAVE* to do joins which I think is bad. In pluggable models the number of columns is user defined so you have control over that and can adjust based on the performance of your project. > > 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 ;) > Having lots of rows is more common than having lots and lots of columns. Breaking data into multiple tables is good DB design and can generally be done by application designers. Dealing with tables with lots of rows is much harder. -- Ian http://www.ianlewis.org/ -- 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.
