6 ms·

Built in everything. Users, auth, admin, ORM. Flask is the opposite: Bring Your Own Everything. It's not hard to replicate the functionality of Django but ther

by speg 9y ago

Built in everything. Users, auth, admin, ORM. Flask is the opposite: Bring Your Own Everything. It's not hard to replicate the functionality of Django but there is surely utility in having everything boxed up and ready to go.

philipov 9y ago
Oh, I get it now. Thanks!
andybak 9y ago
Yes. The joy of reasonable defaults and an opinionated way of working. Some people loathe that but it frees me to think about the customer's actual problem rather than merely tidying my pencil case.
jon_richards 9y ago
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.
- thraxil 9y ago
  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?
  - jastr 9y ago
    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.
    - jon_richards 9y ago
      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.
  - jon_richards 9y ago
    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.
    - thraxil 9y ago
      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?
- photojosh 9y ago
  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. :)

by speg 9y ago

philipov 9y ago

Oh, I get it now. Thanks!

andybak 9y ago

Yes. The joy of reasonable defaults and an opinionated way of working. Some people loathe that but it frees me to think about the customer's actual problem rather than merely tidying my pencil case.

jon_richards 9y ago

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.

thraxil 9y ago
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?
- jastr 9y ago
  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.
  - jon_richards 9y ago
    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.
- jon_richards 9y ago
  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.
  - thraxil 9y ago
    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?
photojosh 9y ago
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. :)