3 ms·

I’ve been developing Django for two weeks and I agree. 1) ORMs have the concept of lazy vs eager, no matter which framework. It’ll bite if you don’t know what

I’ve been developing Django for two weeks and I agree. 1) ORMs have the concept of lazy vs eager, no matter which framework. It’ll bite if you don’t know what you’re doing in any language. They’re still less bad than raw sql. 2) a default user model is better than any attempt an average developer would implement themselves. Go on, I dare you to try and hash passwords correctly. 3) if I wanna know wtf a data migration is for, I’ll look at the commit message, and code changes. 4-6 ) these are opinions of the Django team. I don’t really agree with them, but I chose to use their software. You know what doesn’t have opinions? Raw php, and I know which language/framework I’d prefer..

jmconfuzeus 5y ago
No need to hash password if you subclass AbstractUser. Tell me, if I have {{ customer.auth_user.email }}. Where in this line of code does it say that a SQL query is going to be performed? So much love for lazy queries eh. You're so new to Django and yet you pretend to understand everything. I don't understand how I'm supposed to help someone like you. I hope your tech lead is able to guide you through this.
- Nextgrid 5y ago
  > Where in this line of code does it say that a SQL query is going to be performed? It is implied when you're using a framework with an ORM - after all, how do you end up with a "customer" object to begin with instead of a list representing a DB row? > So much love for lazy queries eh. When it comes to performance there's always a trade-off. The same reasoning could be applied to using Python as opposed to languages that compile to machine code, or for that matter using Linux instead of running your code on bare-metal. Lazy queries trade-off performance in favour of developer productivity. In some cases it's a major problem (fetching 100 objects and looking up related objects for each one), in other cases it might be imperceptible and the time spent fixing them can be probably spent better elsewhere. > You're so new to Django and yet you pretend to understand everything. Knowledge of lazy queries and how they work is definitely valuable, but my impression is that most people here do know how they work and what are their pitfalls - they simply disagree with your opinion that "all lazy queries are bad". > I don't understand how I'm supposed to help someone like you. I hope your tech lead is able to guide you through this. Some people here (including me) don't agree with your black & white thinking about how lazy queries are always bad. They know their application, requirements and performance targets better than you do and have decided that for their use-case lazy queries aren't a problem in most cases (and can address the problematic cases individually without disabling lazy queries globally and having to waste hours trawling through their codebase for every single place to put a select/prefetch_related with no worthwhile performance gain in practice).
ketzu 5y ago
Point 2) is not about implementing authentication or even the user model from scratch. It is about using a custom user model, something the django documentation explicitly recommends doing, for the same reason the author recommends it: Changing it later is a pain. A custom user model doesn't even have to contain anything, it can be empty. See: https://docs.djangoproject.com/en/4.0/topics/auth/customizing/#substituting-a-custom-user-model https://docs.djangoproject.com/en/4.0/topics/auth/customizin... "If you’re starting a new project, it’s highly recommended to set up a custom user model, even if the default User model is sufficient for you." Adding an empty, but custom, user model derived from the base model could be the default. But it isn't, instead there is this recommendation, which you will only read when it is too late (on your first project).
- Nextgrid 5y ago
  I upvoted the article just because of this point as I myself had to go through the pain of moving to a custom user model on an already-deployed app with real data (so nuking the migrations and starting fresh wasn't an option). I agree that most other points are garbage though.

jmconfuzeus 5y ago

No need to hash password if you subclass AbstractUser. Tell me, if I have {{ customer.auth_user.email }}. Where in this line of code does it say that a SQL query is going to be performed? So much love for lazy queries eh. You're so new to Django and yet you pretend to understand everything. I don't understand how I'm supposed to help someone like you. I hope your tech lead is able to guide you through this.

Nextgrid 5y ago
> Where in this line of code does it say that a SQL query is going to be performed? It is implied when you're using a framework with an ORM - after all, how do you end up with a "customer" object to begin with instead of a list representing a DB row? > So much love for lazy queries eh. When it comes to performance there's always a trade-off. The same reasoning could be applied to using Python as opposed to languages that compile to machine code, or for that matter using Linux instead of running your code on bare-metal. Lazy queries trade-off performance in favour of developer productivity. In some cases it's a major problem (fetching 100 objects and looking up related objects for each one), in other cases it might be imperceptible and the time spent fixing them can be probably spent better elsewhere. > You're so new to Django and yet you pretend to understand everything. Knowledge of lazy queries and how they work is definitely valuable, but my impression is that most people here do know how they work and what are their pitfalls - they simply disagree with your opinion that "all lazy queries are bad". > I don't understand how I'm supposed to help someone like you. I hope your tech lead is able to guide you through this. Some people here (including me) don't agree with your black & white thinking about how lazy queries are always bad. They know their application, requirements and performance targets better than you do and have decided that for their use-case lazy queries aren't a problem in most cases (and can address the problematic cases individually without disabling lazy queries globally and having to waste hours trawling through their codebase for every single place to put a select/prefetch_related with no worthwhile performance gain in practice).

ketzu 5y ago

Point 2) is not about implementing authentication or even the user model from scratch. It is about using a custom user model, something the django documentation explicitly recommends doing, for the same reason the author recommends it: Changing it later is a pain. A custom user model doesn't even have to contain anything, it can be empty. See: https://docs.djangoproject.com/en/4.0/topics/auth/customizing/#substituting-a-custom-user-model https://docs.djangoproject.com/en/4.0/topics/auth/customizin... "If you’re starting a new project, it’s highly recommended to set up a custom user model, even if the default User model is sufficient for you." Adding an empty, but custom, user model derived from the base model could be the default. But it isn't, instead there is this recommendation, which you will only read when it is too late (on your first project).

Nextgrid 5y ago
I upvoted the article just because of this point as I myself had to go through the pain of moving to a custom user model on an already-deployed app with real data (so nuking the migrations and starting fresh wasn't an option). I agree that most other points are garbage though.