GSoC 2024 Proposal: Significant Enhancement of Django's bulk_create

Django Internals Mentorship
1

GSoC 2024 Proposal: Significant Enhancement of Django’s `bulk_create

2 Likes
2

hi, i want to when my mentor reviews my project because to submit the project I want this "Project size must match the size that the target organization expects. If you are proposing an idea from an organization list, it should match what is listed there.

Do not change the size (larger or smaller) without getting approval from the target organization first. It may result in your proposal being rejected."

so should I do

3

hi, please be clearer. I don’t think I understood.

if you’re talking about my choice, here are my reasons, explained below

We’re accepting any GSOC proposal that fits one of the following three categories:

  • Work on Django itself - such as the ORM, forms, etc. This is what we’ve traditionally accepted GSoC entries in.

Ideas

Here are some suggestions for projects students may want to propose (please feel free add to this list!). This isn’t by any means the be-all and end-all of ideas; please feel free to submit proposals for things not on this list.

so I’m not obliged to work on what they’ve listed.
at least that’s my interpretation

4

Indeed you’re not obliged @hama. Thank you for the proposal. I’ve only skimmed it, but it looks well researched. I think @charettes would be interested to read it, given you’re quoting his suggestion and intending to work on the ORM.

5

thank you adam for the answer. as mentioned in my proposal:

My commitment to these tickets is independent of the acceptance of this proposal for the Google Summer of Code. I am determined to make these significant contributions to Django, leveraging this opportunity to align my efforts with the GSoC objectives, thereby creating a synergy between my ongoing work and the collaborative and innovative spirit of the program.

i’m already working on orm PR

1 Like
6

Bonjour @HamaBarhamou !

Your research work and lay out plan is effectively very good. I’ll focus on the unique constraint work as that’s an area I have the most details about.

I think you’ll need to spend a bit thinking about your proposal about how you plan to deal with multiple unique constraint as unique_constraints seems to imply you ought to support more than one which I’m not sure how you’ll accomplish as only a single constraint matching the conflict target can be used hence why unique_constraint: str | tuple[str | Expression] was proposed.

Secondly there is a very important nuance that relates to referring to partial unique indices (e.g. UniqueConstraint("foo", condition=Q(deleted_at=None), name="partial_constraint")) that won’t work with your currently proposed solution and it relates to the WHERE clause. I suggest you have a look at the Postgres documentation.

Lastly it’d be great if you could explore what the implementation would look like on other backends like SQLite and possibly explore the usage of the SQL standard MERGE statement. When adding features to the ORM it’s always good to look at how other backends do it to try to come with a generic enough interface that it can abstract common patterns away.

7

Hello @charettes,

Thank you for your detailed feedback on my GSoC proposal regarding bulk_create in Django. Your remarks about handling multiple unique constraints, partial constraints, and compatibility across different databases are highly pertinent.

After a preliminary review of your comments, I recognize the need to delve deeper into certain aspects of my proposal. Therefore, I will take the necessary time to reevaluate my ideas in light of your suggestions and explore additional practices and solutions.

I will reach out with an updated proposal and, if necessary, I won’t hesitate to ask questions to clarify any uncertainties.

Thank you again for your invaluable input at this early stage of the project.

Best regards,