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/c95c7293-1a52-4316-b2ea-c02e18c4aa4dn%40googlegroups.com.
