Two-Spoon Study Session 13

We read Chapters 18, 19, and 20 of Two Scoops of Django together, and worked through how far to customize Django and how to properly use its default features.

Chapter 18 covered replacing Django core, but the conclusion was clear. Without a special reason, there's no need to change core modules, and in particular, forcing a non-relational database onto relational work should be avoided. Instead, the emphasis was on using them appropriately only for cases like cache, queue, and denormalized data—things that need short-term storage or long-term retention.

Chapter 19 looked at the Django admin. Admin is a tool for administrators, not end users, and by default an object's name is shown via __str__(), so it should provide a readable representation. Also, callable methods or functions can be added to ModelAdmin, and admindocs can help with documentation or the skin can be swapped out—but since it comes with significant permissions, care is needed around security and multi-user environments.

Chapter 20 covered how to work with UserModel.

• The user model should be looked up via get_user_model(), and it's safer to use settings.AUTH_USER_MODEL for foreign keys.
• For custom user fields, there are two approaches: extending the existing User by inheriting from AbstractUser, or starting from a more minimal model with AbstractBaseUser.
• Connecting back via a related model is another approach that can be considered.

In the deep-dive part, we went further into topics commonly encountered when actually using admin. Starting from what happens internally in admin.site.register(), we covered defining Actions, filtering exposed data by modifying the queryset, editing alongside a parent model with inline, replacing forms and setting initial values, manipulating the queryset of a ChoiceField, controlling add/change/delete permissions, and even how to create two admin pages for a single model.

Overall, the central message was that rather than flashy techniques, what matters is continually questioning and examining why basic features should be used the way they are. It was only when a question came up about a single piece of example code that a suspicious part was discovered, and it was a session that confirmed how code and study both require more scrutiny the more you look at them.