Changes between Version 10 and Version 11 of Ticket #35941
- Timestamp:
- Dec 2, 2024, 3:29:59 AM (5 weeks ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #35941 – Description
v10 v11 6 6 7 7 1. `object_id` is a `CharField` (or `TextField`) 8 2. ''CompositePrimaryKey'' is stored as a ''JSON array'' in `object_id` 8 2. ''CompositePrimaryKey'' is stored as a ''JSON array'' in `object_id` e.g. `object_id='[1, "abc"]'` 9 9 3. JOINs can be achieved with JSON functions (varies per db backend) 10 10 … … 29 29 30 30 JOIN on JSON functions is not efficient 31 ''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 .''31 ''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).'' 32 32 33 33 **Notes:** … … 41 41 It's possible to implement other strategies to deal with composite generic foreign keys. 42 42 43 1. ''JSONField'' - instead of `CharField` / `TextField`, we could make "object_id" a `JSONField`. This achieves the same thing as my proposal but saves the `::jsonb` cast.44 2. GenericForeignKey with multiple "object_id"s - less flexible, can't store both regular primary keys and composite primary keys.43 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. 44 2. ''GenericForeignKey with multiple `object_id`s'' - less flexible, can't store both regular primary keys and composite primary keys. Fastest JOINs. 45 45 46 There's no reason we couldn't implement other strategies. I believe my proposal provides the most flexibility a nd backwards-compatibility (at the cost of performance).46 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). 47 47 48 48 Any feedback is appreciated!