The difficulty of switching to database level constraint effectively resides in how your lose the great parts of cascade deletion emulations most notably signals post and pre-delete signals.
If you're willing to make this compromise then you must make sure that all cycle of model relationships in your app are also switched to not using post and pre-delete signals as `DB_CASCADE` and `CASCADE` don't play well together. That's easier said than done when using third party applications with limited support for swappable models or that require signals machinery What I meant by that is that you can't have the following models class Foo(models.Model): pass class Bar(models.Model): foo = models.ForeignKey(Foo, on_delete=DB_CASCADE) class Baz(models.Model): bar = models.ForeignKey(Bar, on_delete=CASCADE) As nothing will trigger the Django cascade emulation deletion of Baz when a Bar row gets a database initiated cascade deletion on Foo deletion and you'll run into integrity errors. In the case of signals handling the situation is similar, deleting a Foo object would not trigger a deletion signals for receivers connected to Bar as a sender. A lot of this work has already been done[1] to cover these issues so I consider this problem to be mostly a matter of pushing it through the finish lines and adding extra checks for deletion signal registration on models involved in `DB_CASCADE` chains. While it's true that you can use a `ForeignKeyConstraint(BaseConstraint)` and `db_constraint=DO_NOTHING` to achieve the creation of database constraints at the database level you do loose safe rails that ensures you don't run into surprises in the medium term. Cheers, Simon [1] https://github.com/django/django/pull/14550 Le mercredi 29 mars 2023 à 04:11:55 UTC-4, Carlton Gibson a écrit : > Hey David. > > Nice example! > > I've done this, again just PostgreSQL, overriding the schema > editor's sql_create_fk and sql_create_column_inline_fk to add to the > necessary ON DELETE (for an FK subclass), but doing it with a constraint is > a lovely touch. (I shall play with that 😜) > > I didn't look at all at making it work for each backend (but it should no? > 🤔) > > My need-to-double-check-but… thought on #21961 was that a new kwarg (such > as, say) db_on_delete, which would error if used with on_delete, and set > that to DO_NOTHING, responsible for controlling the generated SQL would be > the way forward here. > > That was all before constraints, though, so thoughts from > Simon/Mariusz/... on best way forward would be good. > > For me, it would be **great** (and akin with various other changes in > recent versions) to be able to push this responsibility into the DB in a > recommended/supported way. > > Kind Regards, > > Carlton > > On Monday, 27 March 2023 at 18:16:37 UTC+2 David Sanders wrote: > >> Hi Akash, >> >> Database-level cascading deletes is a topic that has been discussed often >> since, well probably the dawn of Django 😁 From recollection the main >> issue isn't the implementation, it's getting it to play nicely with >> Django's cascading emulation. >> >> There are other tickets, but I believe this is the main ticket to refer >> to: https://code.djangoproject.com/ticket/21961 There are also plenty >> of threads on this group I'm sure you could dig up. >> >> Note that with the introduction of constraints a while back, there's >> nothing stopping people from adding their own custom foreign keys that adds >> the necessary `ON DELETE` clauses. Here's a demonstration of that: >> https://github.com/shangxiao/stupid-django-tricks/tree/master/abusing_constraints#database-level-cascading-deletes >> >> The gist is: >> >> 1. Set your fks to "do nothing" (I haven't tested with other options >> - seems like there could be some conflicts there though) >> 2. Define your own fk by extending BaseConstraint and add the >> necessary ON DELETE/ON UPDATE clauses >> 3. Add this new fk to your meta's constraints attribute >> >> Check out the tests in that link above for confirmation (only tested on >> Postgres). >> >> Anyway, best of luck! >> David >> >> >> On Tue, 28 Mar 2023 at 00:57, Akash Sen <akashku...@gmail.com> wrote: >> >>> Hello everyone, >>> I’ve started this discussion to get feedback for my proposal for the >>> project: Database-level Cascades Functionality to Django ORM. I have never >>> contributed to any of the official Django projects earlier but I have >>> experience using the framework for last 2 years. In this discussion I would >>> like to propose a high level view of how this can be implemented, any kind >>> of feedback and reference to resources for a more detailed and clear >>> perspective about the project from your side would be very much appreciated, >>> >>> Based on my study it seems quite straightforward and simple to implement. >>> >>> 1. Conduct thorough research and gain an understanding of the >>> existing discussions, pull requests, and issues associated with adding >>> support for database-level cascading options in the Django web framework. >>> 2. Specify the requirements for the new feature, including its name >>> and behavior, and determine whether it should be a new option >>> (on_delete_db) or a modification of the existing one (on_delete). >>> 3. Develop a ForeignKey subclass that sets a flag indicating that >>> the database should manage the cascading options. >>> 4. Modify the DatabaseSchemaEditor’s add_field() and sql_create_fk() >>> methods to recognize the flag and generate SQL accordingly for the >>> specific >>> database backend. >>> 5. Ensure that the implementation performs as intended when tested >>> for a single database backend. Then, generalize the implementation so >>> that >>> it works for all supported database backends, generating appropriate SQL >>> for each. >>> 6. Integrate the implementation with the Django migrations framework >>> to ensure proper handling of database-level cascading options during >>> schema >>> migrations. >>> 7. Write tests to verify that the new feature functions correctly >>> and does not interfere with existing functionality. >>> 8. Submit one or more pull requests containing the changes, and >>> collaborate with the Django community to address any feedback or issues >>> that may arise. >>> >>> Here is a link to my proposal : Database-level Cascades Proposal - GSoC >>> '23 - Google Docs 5 >>> <https://docs.google.com/document/d/1BFKQgcA5qcYpdyzyVBIk52vvvuR_x-6zrzFolJPBaN8/edit?usp=sharing> >>> >>> Due to my beginner level understanding of the codebase there is a lot of >>> scope room for improvement. Your suggestions will be of great help. >>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Django developers (Contributions to Django itself)" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to django-develop...@googlegroups.com. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/django-developers/bd82a0de-8f0a-47b5-b40d-1672ed05736fn%40googlegroups.com >>> >>> <https://groups.google.com/d/msgid/django-developers/bd82a0de-8f0a-47b5-b40d-1672ed05736fn%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >> -- You received this message because you are subscribed to the Google Groups "Django developers (Contributions to Django itself)" group. To unsubscribe from this group and stop receiving emails from it, send an email to django-developers+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/7b2361e8-19e7-4238-b604-f669992f98b6n%40googlegroups.com.
