4 ms·

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 tha

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.

jon_richards 9y ago
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 http://www.giantitp.com/comics/oots0050.html
- thraxil 9y ago
  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?
  - jon_richards 9y ago
    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.

jon_richards 9y ago

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 http://www.giantitp.com/comics/oots0050.html

thraxil 9y ago
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?
- jon_richards 9y ago
  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.