3 ms·

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 que

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).

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).