Opened 3 months ago

Last modified 8 weeks ago

#35941 assigned New feature

Add composite GenericForeignKey support — at Initial Version

Reported by: Csirmaz Bendegúz Owned by:
Component: Database layer (models, ORM) Version: dev
Severity: Normal Keywords:
Cc: Csirmaz Bendegúz, Peter Thomassen Triage Stage: Accepted
Has patch: yes Needs documentation: no
Needs tests: no Patch needs improvement: yes
Easy pickings: no UI/UX: no
Pull Requests:18863 build:success

Description

This is a follow up to #373 (CompositePrimaryKey).

Proposal:

My proposal is to implement GenericForeignKey support with JSON.

  1. object_id is a CharField (or TextField)
  2. CompositePrimaryKey is stored as a JSON array in object_id
  3. JOINs can be achieved with JSON functions (varies per db backend)

If anyone is interested, I have a proof of concept available on my ​GitHub (it's an out of sync draft right now, I'll submit a proper PR once composite primary keys are merged).

Risks:

  1. What if someone is using a JSON array as the primary key (but it's not a composite primary key)?

Before deserializing the JSON array, we need to check if the content type has a composite primary key or not.

  1. What if the db backend doesn't support JSON functions?

All supported databases support JSON functions.

Notes:

Django admin's LogEntry has its own implementation of "generic foreign keys".
The approach we take with GenericForeignKey should also apply to LogEntry.

According to the ticket's flags, the next step(s) to move this issue forward are:

  • To improve the patch as described in the pull request review comments or on this ticket, then uncheck "Patch needs improvement".

  • If creating a new pull request, include a link to the pull request in the ticket comment when making that update. The usual format is: [https://github.com/django/django/pull/#### PR].

Change History (0)

Note: See TracTickets for help on using tickets.
Back to Top