MRO and mixin in Python Django
What Happens When Fields Are Defined in Both the Mixin and the Model?
If a field (or method) is defined in both the mixin and the model:
✅ The model’s definition takes precedence.
Python’s method resolution order (MRO) ensures that the field or method defined in the subclass (your model) overrides the one from the mixin.
🧨 If You Remove Fields from the Model (but they exist in the mixin)
✅ What Happens in Python
Your model still has those fields — because it inherits them from the mixin.
You can still access
obj.failed_scrapy_times, etc.No runtime errors.
⚠️ What Happens in Django Migrations
This is where things get tricky.
Django tracks field definitions per model class, not per inheritance chain.
If you remove a field from the model and it’s only defined in the mixin:
Django will think the field was deleted.
It will generate a migration to drop the column from the database.
🛡️ How to Prevent Unintended Schema Changes
✅ Option 1: Keep the fields in the model
Even if they’re inherited, explicitly define them in the model to keep Django’s migration system happy.
✅ Option 2: Use the mixin only during initial model creation
If you want the mixin to define fields, use it before the first migration — and don’t override those fields in the model later.
✅ Option 3: Manually edit migrations
If you know what you're doing, you can manually adjust the migration file to prevent dropping columns.
🧠 Summary
| Action | Result in Python | Result in DB |
|---|---|---|
| Field defined in mixin only | Works fine | May be dropped by migration |
| Field defined in model | Overrides mixin | Safely tracked by Django |
| Field removed from model | Django may drop it | ⚠️ Risk of data loss |
The best way is to only define methods inside mixin, fields should be defined inside the model
Defining only methods in mixins and keeping fields in the model ensures:
✅ Advantages of Method-Only Mixins
1. Migration Safety
Django’s migration system only tracks fields defined directly in the model.
No risk of fields being dropped or missed due to inheritance ambiguity.
2. Explicit Schema
Your model’s fields are clearly visible and self-contained.
Easier for other developers (or future you!) to understand the database structure.
3. Flexible Reuse
Mixins can be reused across models with different field configurations.
You can customize field behavior per model without touching the mixin.
4. Cleaner Debugging
No surprises from inherited fields during introspection or admin customization.
🧠 Summary
| Approach | Pros | Cons |
|---|---|---|
| Fields in mixin | DRY, reusable | Risky migrations, hidden schema |
| Fields in model, methods in mixin | Explicit, safe, flexible | Slight duplication across models |