Comment by steve_mcdougall | Hacker News Reader

Comment by steve_mcdougall | Hacker News Reader

steve_mcdougall

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.

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.

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

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

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.

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.

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

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.

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

Reply on news.ycombinator.com