Changes between Version 7 and Version 8 of Ticket #35941
- Timestamp:
- Dec 2, 2024, 2:00:29 AM (5 weeks ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
Ticket #35941 – Description
v7 v8 28 28 ''All supported databases support JSON functions.'' 29 29 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.'' 32 30 33 **Notes:** 31 34 … … 34 37 3. Django admin's `LogEntry` has its own implementation of "generic foreign keys". The approach we take with `GenericForeignKey` should also apply to `LogEntry`. 35 38 39 **Alternatives:** 40 41 It's possible to implement other strategies to deal with composite generic foreign keys. 42 43 1. JSONField - instead of `CharField` / `TextField`, we could make "object_id" a `JSONField` 44 2. GenericForeignKey with multiple object_ids - this is less flexible, can't store regular primary keys 45 46 There's no reason we couldn't implement other strategies, I believe the JSON approach provides the most flexibility (at the cost of performance). 47 36 48 Any feedback is appreciated!