Hacker News Reader

Comment by jon_richards | Hacker News Reader

Never use the built in user. Always start a project with a custom user extending abstract user.

At some point you'll want to customize the user in some way (like making the username case insensitive), and you don't want to be dealing with migration dependency conflicts when you do.

For some reason the Django team is really against any attempt to fix that. They're almost hostile in their discussion of it.

View on HN

OK. Well, I've been building Django apps since around 2007/2008. More than 50 deployed to production, many still running/maintained. Never once had a problem using the built-in user model. Do you work in some vertical that makes this a particularly common problem for you?

I don't think the parent comment is saying don't use the built-in user model. The comment is suggesting to sub-class/extend the built-in user model. So you can use much of the built-in functionality and add/change what you'd like, eg. to add a birthday field

There are obviously other ways to do this, perhaps by creating a Profile model that relates to a User.

Yes. Technically you should extend the abstract user model or things get real broken real fast, but that still gives you all the functionality of the built-in user model right out the gate.

The main reason is that if you ever want to change how the username works, it will be a major pain to do if you've been using the built-in user model and already run migrations.

You've never had to extend the user model? I suppose you could just do most extension with a model that has a 1-to-1 with users and use a proxy of the built-in model for the rest, but it seems much simpler to just start out with a user model you can customize easily.

I create Profile's that are mapped 1-to-1 to django.contrib.auth.models.User all the time to hold additional fields. I consider that the "orthodox" approach that Django encourages.

I've even implemented "case-insensitive username" a time or two, but done it by overriding some logic in the login view rather than modifying the user model.

That seems like a lot of trouble when you can just start out a project with a few lines of code extending abstract user. The case-insensitive username can then just be done by making the username a case-insensitive text field (admittedly only available in Postgres, but that's true for a lot of awesome Django features).

I don't mean to be mean, but your answer reminded me a lot of the last row of this comic: http://www.giantitp.com/comics/oots0050.html

But you see, I find that overriding the one little bit of view code (literally a couple lines of code) to change the one thing I want changed is by far the simpler approach rather than changing the whole structure of the user model and introducing who knows what kinds of subtle bugs elsewhere. When the requirement for "case-insensitive username" comes in, it's always turned out that all they really mean is "If someone types 'Bob' in the username field rather than 'bob', it should still work". And again, even that has been such a rare thing that I've probably spent more time writing this comment here than implementing it in code, so why overcomplicate it?

If you change login and forget to change registration, suddenly "Bob" can't login because "bob" just signed up for the service and your login is now returning 2 users. Django puts username validation on the model field for a reason. It's better to have it all centralized.

The nice part about extending the abstract user from the start is that you can still just use it exactly like you'd use the built in user. There's no difference. It just gives you more options in the future.

It literally only takes 8 lines of code, including imports and a "pass" to do.

Heh, wish I'd done this back in 2012 with my app. Admittedly it wasn't as easy to do back then IIRC.

Now one of my to-do-one-day jobs is rolling my UserProfile model back into a custom User subclass... would save a lot of DB queries. :)

Reply on news.ycombinator.com