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 |