[Django] #35941: Add composite GenericForeignKey support

[Django]

#35941: Add composite GenericForeignKey support
-------------------------------------+-------------------------------------
Reporter: Csirmaz Bendegúz | Type: New
| feature
Status: new | Component: Database
| layer (models, ORM)
Version: dev | Severity: Normal
Keywords: | Triage Stage:
| Unreviewed
Has patch: 0 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
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`.
--
Ticket URL: <https://code.djangoproject.com/ticket/35941>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

[Django]

#35941: Add composite GenericForeignKey support
-------------------------------------+-------------------------------------

Reporter: Csirmaz Bendegúz | Owner: (none)

Type: New feature | Status: new

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 Natalia Bidart):

* stage: Unreviewed => Accepted

Comment:

Thank you Ben for creating this ticket. Accepting as described in
ticket:373#comment:204.
--
Ticket URL: <https://code.djangoproject.com/ticket/35941#comment:1>

[Django]

#35941: Add composite GenericForeignKey support
-------------------------------------+-------------------------------------
Reporter: Csirmaz Bendegúz | Owner: (none)
Type: New feature | Status: new
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
-------------------------------------+-------------------------------------

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

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)

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.

--
Comment (by Csirmaz Bendegúz):

Thanks Natalia!
--
Ticket URL: <https://code.djangoproject.com/ticket/35941#comment:2>

[Django]

#35941: Add composite GenericForeignKey support
-------------------------------------+-------------------------------------
Reporter: Csirmaz Bendegúz | Owner: (none)
Type: New feature | Status: new
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
-------------------------------------+-------------------------------------

Comment (by Simon Charette):

I think the proposal looks great Ben, thanks for creating this ticket.

One thing that comes to mind as potentially problematic in JSON array
comparison for `JOIN` is the treatment of Unicode characters as we're
using `json.dumps(ensure_ascii=False)` as well as quotes and other
characters that need to be escaped in JSON. It'd be great to add test
coverage for these.

As for the ''risks'' I appreciate you raising them but I think that
supporting composite generic foreign key composed of standard members
(int, date, datetime, uuid, text) is already a good stretch and I would
feel comfortable saying that anything that falls in the exotic primary key
category should not necessarily be supported in the first place.
--
Ticket URL: <https://code.djangoproject.com/ticket/35941#comment:3>

[Django]

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

[Django]

#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 Peter Thomassen):

* cc: Peter Thomassen (added)

--
Ticket URL: <https://code.djangoproject.com/ticket/35941#comment:5>

[Django]

#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: 1 | Needs documentation: 0

Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Changes (by Csirmaz Bendegúz):

* has_patch: 0 => 1

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

> **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!

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)

*Joins:*

After some experimentation with JSON functions, I believe the simplest
solution is to construct JOINs like this:

{{{
JOIN ON ((object_id::jsonb)->>0)::integer = id
AND ((object_id::jsonb)->>1)::uuid = uuid
}}}

Casting is a pain point, especially when joining on `DateTimeField`s, as
we need to make sure the two columns are in the same format.

**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!

--

--
Ticket URL: <https://code.djangoproject.com/ticket/35941#comment:6>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.

[Django]

#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: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Description changed by Csirmaz Bendegúz:

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

**Joins:**

After some experimentation with JSON functions, I believe the simplest
solution is to construct JOINs like this:

{{{
JOIN ON ((object_id::jsonb)->>0)::integer = id
AND ((object_id::jsonb)->>1)::uuid = uuid
}}}

Casting is a pain point, especially when joining on `DateTimeField`s, as
we need to make sure the two columns are in the same format.

**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!

--
--

Ticket URL: <https://code.djangoproject.com/ticket/35941#comment:7>

[Django]

#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: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Description changed by Csirmaz Bendegúz:

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

JOIN on JSON functions is not efficient
''When storing a composite primary key in a `CharField` / `TextField`,
JSON is the best option we have because it's widely supported by database
backends. To achieve better performance, the composite pk shouldn't be
stored in a `CharField` / `TextField` in the first place.''

**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`.

**Alternatives:**

It's possible to implement other strategies to deal with composite generic
foreign keys.

1. JSONField - instead of `CharField` / `TextField`, we could make
"object_id" a `JSONField`
2. GenericForeignKey with multiple object_ids - this is less flexible,
can't store regular primary keys

There's no reason we couldn't implement other strategies, I believe the
JSON approach provides the most flexibility (at the cost of performance).

Any feedback is appreciated!

--
--

Ticket URL: <https://code.djangoproject.com/ticket/35941#comment:8>

[Django]

"object_id" a `JSONField`. This achieves the same thing as my proposal but
save the `::jsonb` cast.
2. GenericForeignKey with multiple object_ids - less flexible, can't store
both regular primary keys and composite primary keys.

There's no reason we couldn't implement other strategies. I believe my
proposal provides the most flexibility and backwards-compatibility (at the

cost of performance).

Any feedback is appreciated!

--
--

Ticket URL: <https://code.djangoproject.com/ticket/35941#comment:9>

[Django]

saves the `::jsonb` cast.
2. GenericForeignKey with multiple "object_id"s - less flexible, can't

store both regular primary keys and composite primary keys.

There's no reason we couldn't implement other strategies. I believe my
proposal provides the most flexibility and backwards-compatibility (at the
cost of performance).

Any feedback is appreciated!

--
--

Ticket URL: <https://code.djangoproject.com/ticket/35941#comment:10>

[Django]

> but saves the `::jsonb` cast.
> 2. GenericForeignKey with multiple "object_id"s - less flexible, can't
> store both regular primary keys and composite primary keys.
>
> There's no reason we couldn't implement other strategies. I believe my
> proposal provides the most flexibility and backwards-compatibility (at
> the cost of performance).
>
> Any feedback is appreciated!

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`

e.g. `object_id='[1, "abc"]'`

3. JOINs can be achieved with JSON functions (varies per db backend)

**Joins:**

After some experimentation with JSON functions, I believe the simplest
solution is to construct JOINs like this:

{{{
JOIN ON ((object_id::jsonb)->>0)::integer = id
AND ((object_id::jsonb)->>1)::uuid = uuid
}}}

Casting is a pain point, especially when joining on `DateTimeField`s, as
we need to make sure the two columns are in the same format.

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

JOIN on JSON functions is not efficient
''When storing a composite primary key in a `CharField` / `TextField`,
JSON is the best option we have because it's widely supported by database
backends. To achieve better performance, the composite pk shouldn't be

stored in a `CharField` / `TextField` in the first place (see:
alternatives).''

**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`.

**Alternatives:**

It's possible to implement other strategies to deal with composite generic
foreign keys.

1. ''JSONField'' - instead of `CharField` / `TextField`, we could make

"object_id" a `JSONField`. This achieves the same thing but saves the
`::jsonb` cast, so it's slightly faster.

2. ''GenericForeignKey with multiple `object_id`s'' - less flexible, can't

store both regular primary keys and composite primary keys. Fastest JOINs.

There's no reason we couldn't implement other strategies. I believe my

proposal provides the most flexibility at the cost of performance. It
should be implemented for backwards-compatibility, so systems using a
`CharField` ''object_id'' (e.g. [https://github.com/django-guardian
/django-
guardian/blob/55beb9893310b243cbd6f578f9665c3e7c76bf96/guardian/models/models.py#L39
django-guardian]) can easily integrate with composite primary keys. Other
strategies can then be implemented to improve performance (or other
reasons).

Any feedback is appreciated!

--
--

Ticket URL: <https://code.djangoproject.com/ticket/35941#comment:11>

[Django]

#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: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 0
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------
Description changed by Csirmaz Bendegúz:

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`

`CharField` / `TextField` ''object_id'' (e.g. [https://github.com/django-

guardian/django-
guardian/blob/55beb9893310b243cbd6f578f9665c3e7c76bf96/guardian/models/models.py#L39
django-guardian]) can easily integrate with composite primary keys. Other

strategies can then be implemented to improve performance.

Any feedback is appreciated!

--
--

Ticket URL: <https://code.djangoproject.com/ticket/35941#comment:12>

[Django]

> `CharField` / `TextField` ''object_id'' (e.g. [https://github.com/django-
> guardian/django-
> guardian/blob/55beb9893310b243cbd6f578f9665c3e7c76bf96/guardian/models/models.py#L39
> django-guardian]) can easily integrate with composite primary keys. Other
> strategies can then be implemented to improve performance.
>
> Any feedback is appreciated!

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`
e.g. `object_id='[1, "abc"]'`
3. JOINs can be achieved with JSON functions (varies per db backend)

**Joins:**

After some experimentation with JSON functions, I believe the simplest
solution is to construct JOINs like this:

{{{
JOIN ON ((object_id::jsonb)->>0)::integer = id
AND ((object_id::jsonb)->>1)::uuid = uuid
}}}

Casting is a pain point, especially when joining on `DateTimeField`s, as
we need to make sure the two columns are in the same format.

**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. MariaDB has some
limitations handling surrogate pairs.''

Ticket URL: <https://code.djangoproject.com/ticket/35941#comment:13>

[Django]

#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: 1 | Needs documentation: 0

Needs tests: 0 | Patch needs improvement: 1

Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Changes (by Sarah Boyce):

* needs_better_patch: 0 => 1

--
Ticket URL: <https://code.djangoproject.com/ticket/35941#comment:14>

[Django]

#35941: Add composite GenericForeignKey support
-------------------------------------+-------------------------------------

Reporter: Csirmaz Bendegúz | Owner: (none)
Type: New feature | Status: new

Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Changes (by Csirmaz Bendegúz):

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

Comment:

I don't have the time to work on this right now
--
Ticket URL: <https://code.djangoproject.com/ticket/35941#comment:15>

[Django]

#35941: Add composite GenericForeignKey support
-------------------------------------+-------------------------------------

Reporter: Csirmaz Bendegúz | Owner: jengziyi

Type: New feature | Status: assigned

Component: Database layer | Version: dev
(models, ORM) |
Severity: Normal | Resolution:
Keywords: | Triage Stage: Accepted
Has patch: 1 | Needs documentation: 0
Needs tests: 0 | Patch needs improvement: 1
Easy pickings: 0 | UI/UX: 0
-------------------------------------+-------------------------------------

Changes (by jengziyi):

* owner: (none) => jengziyi

* status: new => assigned

--
Ticket URL: <https://code.djangoproject.com/ticket/35941#comment:16>

[Django]

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

Comment (by Simon Charette):

Note that this slightly relates to #23268 as the latter needs a way to
serialize a natural key that might be composed of multiple fields.
--
Ticket URL: <https://code.djangoproject.com/ticket/35941#comment:17>