GSOC 2023 Discussion and Feedback: Database-level Cascades

Django Internals Mentorship
1

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

Due to my beginner level understanding of the codebase there is a lot of scope room for improvement. Your suggestions willbe of great help.

1 Like
2

Hi @felixxm and @charettes approaching you for your name in the possible mentors list for the project Database-level Cascades, got any feedback for me? Or I should go ahead submitting the proposal?

3

I left some feedback on the Google document. I can summarize it to

  1. I also agree that a standalone db_on_delete kwarg is a better option than trying to stash everything in db_delete but I think the debate is not settled yet and you should be able to provide some strong rationale about why this is a better option.
  2. The document mentions creating foreign key and migration operation subclasses to deal with this new option. I don’t think creating subclasses is desirable as we want this option to be available by simply changing their db_on_delete option.
  3. You go into a lot of details about testing schema parts but I think there are other areas that worth a more detailed breakdown in terms of testing. This is a model deletion feature first and foremost.

Otherwise the document is looking like a great submission. I would strongly encourage you to work on other entry/mid-entry level ORM/migration tickets before venturing into this process as it was demonstrated to be good way to demonstrate your ability to tackle long standing ORM tickets.

1 Like