5 ms·

All of these "issues" are well documented if you bother to read just the main Django documentation. Some solutions are questionable. Executing querysets as soo

All of these "issues" are well documented if you bother to read just the main Django documentation. Some solutions are questionable. Executing querysets as soon as you define them means you can't compose them. Lazy quersets are not dangerous and you don't execute that many because they are lazy, but because under the hood you haven't asked for a JOIN statement. Automatic database table names are definitely not a problematic feature. 99% of the time it gives you very intuitive mapping between model name and database table name. If you actually want to move model to a different app, then you can use the same feature (db_table) to point to its old location. This article would benefit from more humility.

jmconfuzeus 5y ago
I wrote this post for beginners and most of them never read the docs before hacking on production code. Lazy querysets aren't dangerous but it's always best to evaluate them before rendering anything in order to avoid secret SQL queries. Many developers never run EXPLAIN, so these extra queries go unnoticed until your server crashes during Black Friday. I don't see why your database table needs to encapsulate the app's name. Most apps get rewritten at some point but databases can live for centuries. Why couple code with your data? Maybe I should be more humble to please sensitive people like you but no thanks. If a simple blog post hurts your feelings then you need to professional help.
- Nextgrid 5y ago
  > I don't see why your database table needs to encapsulate the app's name. Because Django assumes that in most cases your DB will be primarily (only?) be used by the Django app. In my experience that is true of most startups and early-stage projects, and the default names have never been a blocker even when you start giving others access to that database (hopefully with a read-only user account). > Most apps get rewritten at some point but databases can live for centuries. You can rename tables when this becomes needed. I don't think it's worth wasting time doing so at the beginning (you could equally argue that whatever name you pick manually isn't going to be suitable in the future either, so a rename will be needed either way). > Why couple code with your data? Renaming tables doesn't realistically address that coupling by any means.
j4mie 5y ago
Just to note: django-zen-queries doesn’t encourage you to execute querysets as soon as you define them, but rather just before you pass them to a template or serializer. This is a pattern we’ve found really useful. (I’m the author of django-zen-queries) I’m not a fan of the hyperbole in the article either. Some of the points are genuine problems but none of them should put off beginners.
- bluewalt 5y ago
  I just found out this package and absolutely love the idea of "sanitizing" the queries. However I'm just wondering: if I'm a solo dev and I already monitor all my endpoints using Django Debug toolbar, how is it still useful to use this package?
  - Nextgrid 5y ago
    I doubt it. In my entire career I've got away with just relying on a "gut feeling" about whether a query needs a select/prefetch_related and it has yet to fail me. Yes, you're going to have a handful of stray queries here and there that could technically be avoided, but is the extra developer effort worth it? Hardware is very cheap (well if you know where to look, definitely don't look in the clouds), take advantage of that. Unless you're programming purely for the sake of programming, what matters is the end result and the problem your application is solving. Your code doesn't have to be 100% perfect (otherwise why are you using a dynamically-typed, interpreted language?), it just has to work well enough to solve the business problem - other tools such as monitoring will quickly tell you if you've made a mistake and you can go back to the drawing board and add that extra select/prefetch_related you missed the first time.
- stavros 5y ago
  As an experienced Django developer, I found django-zen-queries very good for hygiene, and I'm going to start using it. I should also pay attention to django-debug-toolbar's query view more often. I generally don't need to optimize my queries because my apps are small, but I should do that by default, because otherwise it's wasteful and it's not hard to do. It's just that Django's default doesn't encourage you too, but hopefully with Zen Queries it will.

jmconfuzeus 5y ago

I wrote this post for beginners and most of them never read the docs before hacking on production code. Lazy querysets aren't dangerous but it's always best to evaluate them before rendering anything in order to avoid secret SQL queries. Many developers never run EXPLAIN, so these extra queries go unnoticed until your server crashes during Black Friday. I don't see why your database table needs to encapsulate the app's name. Most apps get rewritten at some point but databases can live for centuries. Why couple code with your data? Maybe I should be more humble to please sensitive people like you but no thanks. If a simple blog post hurts your feelings then you need to professional help.

Nextgrid 5y ago
> I don't see why your database table needs to encapsulate the app's name. Because Django assumes that in most cases your DB will be primarily (only?) be used by the Django app. In my experience that is true of most startups and early-stage projects, and the default names have never been a blocker even when you start giving others access to that database (hopefully with a read-only user account). > Most apps get rewritten at some point but databases can live for centuries. You can rename tables when this becomes needed. I don't think it's worth wasting time doing so at the beginning (you could equally argue that whatever name you pick manually isn't going to be suitable in the future either, so a rename will be needed either way). > Why couple code with your data? Renaming tables doesn't realistically address that coupling by any means.

j4mie 5y ago

Just to note: django-zen-queries doesn’t encourage you to execute querysets as soon as you define them, but rather just before you pass them to a template or serializer. This is a pattern we’ve found really useful. (I’m the author of django-zen-queries) I’m not a fan of the hyperbole in the article either. Some of the points are genuine problems but none of them should put off beginners.

bluewalt 5y ago
I just found out this package and absolutely love the idea of "sanitizing" the queries. However I'm just wondering: if I'm a solo dev and I already monitor all my endpoints using Django Debug toolbar, how is it still useful to use this package?
- Nextgrid 5y ago
  I doubt it. In my entire career I've got away with just relying on a "gut feeling" about whether a query needs a select/prefetch_related and it has yet to fail me. Yes, you're going to have a handful of stray queries here and there that could technically be avoided, but is the extra developer effort worth it? Hardware is very cheap (well if you know where to look, definitely don't look in the clouds), take advantage of that. Unless you're programming purely for the sake of programming, what matters is the end result and the problem your application is solving. Your code doesn't have to be 100% perfect (otherwise why are you using a dynamically-typed, interpreted language?), it just has to work well enough to solve the business problem - other tools such as monitoring will quickly tell you if you've made a mistake and you can go back to the drawing board and add that extra select/prefetch_related you missed the first time.
stavros 5y ago
As an experienced Django developer, I found django-zen-queries very good for hygiene, and I'm going to start using it. I should also pay attention to django-debug-toolbar's query view more often. I generally don't need to optimize my queries because my apps are small, but I should do that by default, because otherwise it's wasteful and it's not hard to do. It's just that Django's default doesn't encourage you too, but hopefully with Zen Queries it will.