[cessor]

The author names three 'harmful' defaults:

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`

[jmconfuzeus]

I consider them harmful for beginners who need to start working on non trivial production code.

Multiple apps are definitely good for the admin but what I was advocating isn't 100% avoidance of apps but to avoid creating apps for every tiny feature.

Personally, I like my databases to be designed for longevity and avoid couple code to my data. Code can die at any point in time but data is an asset that needs to live for as long as the company is in operation.

[Nextgrid]

> beginners who need to start working on non trivial production code.

If you're a beginner dropped into a non-trivial production codebase your best bet is to follow existing conventions until you gain enough experience to be able to evaluate such advice and consider it against your projects' and business' requirements.