Harmful Defaults in Django

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

Furthermore, this:

> As you can see, Django doesn’t have your best interest at heart. Instead of providing sane defaults, it punishes you for not being a master at the framework.

Is just nonsense.

Regarding 1. While this is certainly an issue, it’s an issue for anyone using any framework and a challenge of database-backed web applications everywhere. It’s also heavily documented by Django and one of the first things mentioned. Lazy querysets are actually very useful when you need to build queries over a number of steps. Explicit query sets can have their own subtle issues with performance.

2. The default user model is fine for most users. It’s not a bad default and there is clear documentation on how to extend it. It’s designed to be extended!

3. I rarely rename migrations. Maybe this is a good idea, but it’s hardly a harmful default.

4. I almost never rename my tables. Again, maybe a sensible suggestion, not a harmful default.

5. Strangely this seems to be the most un-Django suggestion that would have the largest effect on a project but hardly any detail is given here. I never do this and wouldn’t recommend anyone else to when staring off.

6. I think project structure and CLI is one place where Django is weak but again this is hardly a harmful default. Use django-cookiecutter.

Anyway I feel like the author is trying to manufacturer controversy to help define their expertise (not to say they aren’t a good Django developer, I have no idea). Some of these are good suggestions and “top tips” but they’re certainly not instances of Django trying to harm you.

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.

Meta point: I really enjoy articles that list the places noobies go wrong (for any language/framework, not exclusively django). E.g. an experienced dev I taught R to was mind-blown that vec[1] accesses the first element of a vector (not vec[0]).

Long lists of these unexpected (albeit simple) things can quickly be compiled. It might only take 30 minutes for a noobie to read but probably ends up saving days of pain down the track.

1. Relying on implicit SQL queries

2. Using the default User model

3. Using automatic migration names

4. Relying on automatic database table names

5. Using multiple tiny apps

6. Dumping apps in the root directory

I wouldn't call those harmful. Most are non-issues, while others are "unfortunate" at best.

1. I found that the ORM works quite well and it's easy to optimize later. Using `prefetch_related` or `select_related` in the ORM still feels weird (they're just joins), but I wouldn't call them harmful.

2. I found it unfortunate that the info on how to change the User model is hidden so deep in the Documentation. I don't like to RTFM, but with Django it sure is worth it; same goes for 1.

3. I occasionally do it, but most of the time, I don't and never had an issue.

4. It do rely on that and found django's naming scheme to be a non-issue. I guess this might be more important if you need to change your database out of band (out of django band, that is)

5. This point is unsubstantiated. Apps aren't mere packages but also define a scope for the admin tool (which I use a lot and think is an integral part of Django) so that it will group models and allow individual access (i.e. apps also provide scope for your permissions). I use tons of apps but I wouldn't call it a harmful default.

6. Yeah, dynamic languages might produce naming collisions. Still beats imports like `org.example.publib.boulder.yourmoms.maidenname.models.impl.Account`

I wouldn’t say any of these are “harmful”, there are certainly some things here that have valid arguments for doing differently, but most is rubbish. But it needs to be taken into account that Django is an incredibly mature framework with literally millions of projects built on it. Large changes are hard, and Django has had to make many of them before. All of these have been debated and haven’t changed either due to immovable technical debt, a decision that there isn’t at this time a need, or there is valid arguments on both sides.

A couple of examples: the user model, providing a default is important but it is also well documented that if you want to extend it you should subclass it from the beginning to make your life easier. There are ways to migrate later, they aren’t exactly easy, but it is doable.

Multiple small apps, this architecture is due to the history of Django and its development at LWJ. They wanted a way of being able to quickly build new websites out of pre-defined “apps”, and this system works for that. At the time the Python packaging ecosystem was very different, hence then slightly odd design. I’m sure in hindsight the founding team would have done things differently, but this is 17 years ago.

The general rule of thumb for “app” architecture now with Django is if you are a consultancy/agency building multiple similar sites for multiple clients (this is a huge use case for Django, closest to it original vision) it makes sense to package up your functionality into reusable apps. If you are a “startup” or building an internal app for a company with no need for reusability it’s best to just have one “core” app to contain all your functionality. It comes down to your personal needs, but it’s easy to make both architectures work.

You also avoid merge conflicts in teams, especially with migrations. I'm now working with Dotnet, because I have to (nobody wants to hire me as a Django developer even though I have 10+ years experience in Django and <0.5y in .NET), and this is an ongoing problem with EF core...

My real criticism of Django is that, at long last, I think it's starting to look dated. Templating hasn't been the preferred way of making web app UIs for some time. Modern web apps are maintaining models in the client and staying current though a combination of ajax queries and websockets. Setting up a project to do this is cumbersome. While there are third party solves, Django's greatness comes in part from how opinionated it is.

I understand DSF may see adding more javascript as out of scope, but in keeping with the "batteries included" philosophy I hope they one day embrace something in contrib.

But the first pain point I very much agree with. Implicitly sending queries to the backend is one of those things that is an attempt to be very helpful to programmers, but that ends up as an obstacle that you always need to be wary of and avoid. Over time I have grown to appreciate explicitness in queries more and more, though I probably wouldn't go so far to remove lazy queries completely since they can be handy in query building, just remove the implicit loading feature if possible.

Django's query builder is also quite far removed from SQL. Especially once you get into more complex queries, I sometimes just went raw SQL as I knew I wouldn't be able to remember how to translate the Django expression into SQL in a month's time. Simple queries are easy to write and look very sleek, but complex ones can turn into a mess that is much more understandable in SQL form. The sleekness of the queries may also betray how complex they are to execute as it's not "in your face".

I still like Django's ORM quite a bit for many things, but after discovering Elixir's Ecto, I've enjoyed how explicit it is most of the time. I haven't needed implicit loading of relations once. It's also much closer to actual SQL. But there are things where Ecto also tries to be too helpful in my taste, like the humanised types in migrations (i.e. :utc_datetime instead of :timestamptz or :string instead of :"character varying"/:text) -- I strongly believe it would be easier in the long run for the programmer to specify the database types they want directly rather than through aliases which may result in surprising choices. Of course, that would cause issues in supporting multiple different databases, but that's not a goal I would go for in the first place, but I digress…

What I guess I'm saying is that sometimes projects build in helpful features to make the code nicer to look at, more approachable to beginners, or just shorter to write, but they often end up being a burden on those that go past the beginner stage. People invariably trip on them because who can remember everything mentioned in all the documentation? And then it's just a game of "who fails to avoid the trap every time" and that's a game that everyone loses eventually.

The only sane way is to think about tables first, create models that mimic those tables, use makemigrations + migrate and absolutely no inheritance in the models.

An extra bonus is only one app per project. I've got a customer with two projects: one with many apps and a lot of inheritance, the other one with one big app and a few very small ones and no inheritance. We can use any SQL tool to extract data from the database of the second project. The database of the first one is "spaghetti data" and "python3 manage.py shell" is the only way to make sense of it.

On the other side we could say that at last a djangified database is a truly object oriented database.

I think this should be the default behaviour given that most beginning Django developers fall into this trap.

Proper abstraction is the one thing you need to get right, and django makes it so easy to make clean separate modules work together using a shared base and way of working (user model, groups, permissions, urls, signals, etc.).

One day you'll need to use your payments logic to sell something else, embrace it.