Google Summer of Code 2024 Final Report

GSoC-2024-Final-Report.md

• Name: Bendegúz Csirmaz
• Organization: Django Software Foundation
• Mentors: Lily Foote, Simon Charette, Carlton Gibson
• Project: Own Idea
• Proposal: Django ORM support for composite primary keys
• Ticket: #373
• Forum: GSoC 2024 proposal: Django ORM support for composite primary keys
• GitHub: Fixed #373 -- Added CompositePrimaryKey.

Project Goals

The goal of the project was to add composite primary key support to the Django ORM.

The primary goal was to add composite primary key support to:

1. Migrations
2. QuerySet API (e.g. .get(), .create(), etc.)
3. AutoFields

The secondary goal was to add composite primary key support to:

1. ForeignKeys
2. GenericRelations
3. Admin

Goals Achieved

I've managed to prepare multiple pull requests addressing all aspects of the project, most of which are waiting for review.

Accepted

The work that got accepted and merged upstream:

1. Added tuple lookups to Django, a pre-requisite for both composite primary keys and composite foreign keys.
2. Added Model._is_pk_set(), a small refactoring introducing a utility function necessary for composite primary keys. [edited 10/09/2024]
3. CompositePrimaryKey is the project's most important pull request, it introduces the CompositePrimaryKey field. [edited 29/11/2024]

Pending

The work yet to get accepted or rejected:

1. Composite GenericForeignKeys adds composite primary key support to GenericForeignKeys by storing composite primary keys as a JSON array.
2. Composite ForeignKeys adds composite foreign key support to the ForeignKey class by introducing the from_fields, to_fields arguments.
3. Composite PKs in admin adds composite primary key support to Django admin.

Rejected

The work that got rejected:

1. SerialFields was an attempt to encourage the use of surrogate keys inside composite primary keys. We've agreed to use AutoFields instead, but this will only become relevant once composite primary keys have landed.

Related Issues

Although these issues are NOT part of the project's goals, they are related to the project.

1. Add generic CompositeFields. Once the CompositePrimaryKey field has been merged, it can be used as a reference for implementing the CompositeField field. CompositePrimaryKey may be deprecated in favour of CompositeField in the future (#5929).
2. Tuple Lookups as a public API. Once composite primary keys are merged, tuple lookups can be a exposed as a public API. There has been some interest in this area on the forum.
3. The primary key shouldn't be editable on the admin (#2259). This applies to both composite and non-composite primary keys.

Final Thoughts

We've shown that composite primary keys are not only possible to implement, they can be implemented in a relatively simple way.

Although the project hasn't been merged yet, the work I've submitted is ready for review, and it will eventually land in one of the upcoming releases in one form or another.

Thank you,

• Lily Foote and Simon Charette for your dedication to this project! Your insightful feedback is always much appreciated.
• Sarah Boyce and Natalia Bidart for supporting me in getting this project done.
• Carlton Gibson for the encouraging words, if not for you, I may have not applied to GSoC.