#35941: Add composite GenericForeignKey support
-------------------------------------+-------------------------------------
     Reporter:  Csirmaz Bendegúz     |                    Owner:  Csirmaz
                                     |  Bendegúz
         Type:  New feature          |                   Status:  assigned
    Component:  Database layer       |                  Version:  dev
  (models, ORM)                      |
     Severity:  Normal               |               Resolution:
     Keywords:                       |             Triage Stage:  Accepted
    Has patch:  0                    |      Needs documentation:  0
  Needs tests:  0                    |  Patch needs improvement:  0
Easy pickings:  0                    |                    UI/UX:  0
-------------------------------------+-------------------------------------
Changes (by Csirmaz Bendegúz):

 * owner:  (none) => Csirmaz Bendegúz
 * status:  new => assigned


Old 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
> [https://github.com/csirmazbendeguz/django/pull/9 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.''
> 2. 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`.
>
> If someone has a better proposal or feedback on my proposal I would be
> happy to hear it.

New 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)

 **Risks:**

 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.''

 What if the db backend doesn't support JSON functions?
 ''All supported databases support JSON functions.''

 **Notes:**

 1. JOINs must work with Unicode characters
 2. int, date, datetime, uuid, text fields must be supported
 3. Django admin's `LogEntry` has its own implementation of "generic
 foreign keys". The approach we take with `GenericForeignKey` should also
 apply to `LogEntry`.

 Any feedback is appreciated!

--
Comment:

 Yes, thanks for raising these points Simon!
-- 
Ticket URL: <https://code.djangoproject.com/ticket/35941#comment:4>
Django <https://code.djangoproject.com/>
The web framework for perfectionists with deadlines.

-- 
You received this message because you are subscribed to the Google Groups 
"Django updates" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To view this discussion visit 
https://groups.google.com/d/msgid/django-updates/01070193780ad140-b2960553-e457-4fff-8626-414b76dd3693-000000%40eu-central-1.amazonses.com.

Reply via email to