4 ms·

Wow this article is so poor it is almost malicious. > This means that you don’t own your database — the Django foundation does! This is a completely baseless

Wow this article is so poor it is almost malicious. > This means that you don’t own your database — the Django foundation does! This is a completely baseless accusation. At no point are you unable to change the schema or replace the user model (which we have done with admittedly some kerfuffle). If the author is reading this comment, and this is the reaction you were looking for from the community. Congratulations. You have written a completely asinine article about a technology you obviously do not understand yourself. Telling people to rename tables because "a future data analyst is not going to know what a table is for". On what planet is a data analyst given raw access to the production instance's tables of a database and not a view on a read replica. Having one migration per model is dumb as all hell, as you would need to manually separate these, achieving nothing of value in the process. Know-it-all anuses like the author of the article is why software engineering has become to be known as "a black hole of cash" because these are the type of people who pretend to know what they are talking about but make decisions that cost people exponential money and time. Please stop writing sensationalist, clickbait bullshit like this and please, please read at least a small part of the documentation before writing something misleading like this.

jmconfuzeus 5y ago
1. How are you supposed to change the concrete User model that Django provides without forking Django itself? It's 1000x better to subclass AbstractUser and provide your own User model that you own. 2. One migration file per model is easier to manage. It's my opinion of course, but think about how you'd squash migrations for old models if you're in the habit of bundling multiple RunPython or RunSQL methods in the same migration file. I wish you'd think straight instead of being angry. It's not like I'm claiming that the earth is flat.
- Nextgrid 5y ago
  > One migration file per model is easier to manage. It's my opinion of course, but think about how you'd squash migrations for old models if you're in the habit of bundling multiple RunPython or RunSQL methods in the same migration file. Squashing is something Django will handle for you through a management command, at which point it doesn't matter whether you're doing one model per migration file or not. Stuff that cannot be squashed (RunSQL/Python operations) will be pointed out by Django and I'm not sure how having one model per migration will help - the difficulty here isn't locating the offending operation, it's to actually figure out whether that operation is still needed and if so whether it can be reworked.
nerdponx 5y ago
I was a data analyst working at a company where all the data was in a Django-mamaged database. Not once was I confused by the table or column naming. I was kind of annoyed by all the long table names and all the joins I had to write out, but it was all fairly tidy and organized, and I almost prefer it to the human-designed databases I've worked with. Theoretically yes if they one day renamed the app then there would be some legacy names in the table. Who cares, shit happens. Regarding read-only access: we were a small enough organization that I actually did have full access to the prod database. I hated having it and tried to work off of our "QA" clone whenever possible, or made my own local timestamped copy of the prod data.
hsbauauvhabzb 5y ago
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).

jmconfuzeus 5y ago

1. How are you supposed to change the concrete User model that Django provides without forking Django itself? It's 1000x better to subclass AbstractUser and provide your own User model that you own. 2. One migration file per model is easier to manage. It's my opinion of course, but think about how you'd squash migrations for old models if you're in the habit of bundling multiple RunPython or RunSQL methods in the same migration file. I wish you'd think straight instead of being angry. It's not like I'm claiming that the earth is flat.

Nextgrid 5y ago
> One migration file per model is easier to manage. It's my opinion of course, but think about how you'd squash migrations for old models if you're in the habit of bundling multiple RunPython or RunSQL methods in the same migration file. Squashing is something Django will handle for you through a management command, at which point it doesn't matter whether you're doing one model per migration file or not. Stuff that cannot be squashed (RunSQL/Python operations) will be pointed out by Django and I'm not sure how having one model per migration will help - the difficulty here isn't locating the offending operation, it's to actually figure out whether that operation is still needed and if so whether it can be reworked.

nerdponx 5y ago

I was a data analyst working at a company where all the data was in a Django-mamaged database. Not once was I confused by the table or column naming. I was kind of annoyed by all the long table names and all the joins I had to write out, but it was all fairly tidy and organized, and I almost prefer it to the human-designed databases I've worked with. Theoretically yes if they one day renamed the app then there would be some legacy names in the table. Who cares, shit happens. Regarding read-only access: we were a small enough organization that I actually did have full access to the prod database. I hated having it and tried to work off of our "QA" clone whenever possible, or made my own local timestamped copy of the prod data.

hsbauauvhabzb 5y ago

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