基于遗留MySQL库生成Django模型：on_delete参数是否需调整？

Hey, great question—let’s break this down so it’s crystal clear for your use case.

Your MySQL database will 100% respect the constraints you defined in your custom SQL script, regardless of what on_delete values are set in your Django models. That said, whether you need to adjust those on_delete parameters depends on how you plan to use the Django ORM with your existing database.

1. Database Constraints vs. Django's on_delete #

Let’s clarify the critical distinction here:

• Database-side constraints: The ON DELETE rules you set in your SQL (like CASCADE, RESTRICT, SET NULL) are stored directly in MySQL. The database engine enforces these automatically, no matter what Django does. If you delete a parent record that has dependent child records, MySQL will follow your original constraint rules—full stop.
• Django's on_delete: This is an ORM-level setting that tells Django how to behave when you try to delete an object via the ORM. It does not modify or override your database’s existing constraints. It’s purely about Django’s pre-processing before sending the delete request to the database.

2. What DO_NOTHING Means Right Now #

The on_delete=models.DO_NOTHING generated by inspectdb does exactly what it says:

• When you try to delete a parent object via Django’s ORM, Django won’t take any action on related child objects—it’ll just send the delete command straight to MySQL.
• MySQL will then execute your original constraint. For example:
  • If your SQL used ON DELETE CASCADE, MySQL will automatically delete all dependent child records.
  • If your SQL used ON DELETE RESTRICT, MySQL will throw an IntegrityError, which Django will bubble up to your code (you’ll need to handle this exception if you don’t want crashes).

3. Should You Modify the on_delete Parameters? #

It depends on how you’ll use the Django API:

• If you’re only using Django for read operations: You can leave DO_NOTHING as-is. Since you’re not deleting anything via the ORM, the setting won’t affect your database’s normal operation.
• If you need to perform deletions via the ORM: It’s a good idea to align on_delete with your database’s actual constraints. For example:
  • If your SQL uses ON DELETE CASCADE, set on_delete=models.CASCADE—this makes Django’s ORM behavior match the database’s, so you won’t get unexpected exceptions.
  • If your SQL uses ON DELETE RESTRICT, set on_delete=models.RESTRICT—this lets Django check for dependent records before sending the delete request, giving you a cleaner, more predictable error in your code instead of a raw database exception.
    Aligning these values makes your code more readable and avoids confusing mismatches between ORM behavior and database rules.

4. A Quick Note on managed=False #

Your choice to set managed=False is perfect for this use case—it tells Django not to try creating, altering, or dropping tables, which is exactly what you want when using Django as a read/write API for an existing database. No changes needed here.

内容的提问来源于stack exchange，提问作者iMusic