Changes between Version 2 and Version 4 of Ticket #35941


Ignore:
Timestamp:
Nov 29, 2024, 7:09:54 AM (6 weeks ago)
Author:
Csirmaz Bendegúz
Comment:

Yes, thanks for raising these points Simon!

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #35941

    • Property Owner set to Csirmaz Bendegúz
    • Property Status new → assigned

  • Ticket #35941 – Description

    v2 v4  
    993. JOINs can be achieved with JSON functions (varies per db backend)
    1010
    11 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).
    12 
    1311**Risks:**
    1412
    15 1. What if someone is using a JSON array as the primary key (but it's not a composite primary key)?
     13What if someone is using a JSON array as the primary key (but it's not a composite primary key)?
    1614''Before deserializing the JSON array, we need to check if the content type has a composite primary key or not.''
    17 2. What if the db backend doesn't support JSON functions?
     15
     16What if the db backend doesn't support JSON functions?
    1817''All supported databases support JSON functions.''
    1918
    2019**Notes:**
    2120
    22 Django admin's `LogEntry` has its own implementation of "generic foreign keys".
    23 The approach we take with `GenericForeignKey` should also apply to `LogEntry`.
     211. JOINs must work with Unicode characters
     222. int, date, datetime, uuid, text fields must be supported
     233. Django admin's `LogEntry` has its own implementation of "generic foreign keys". The approach we take with `GenericForeignKey` should also apply to `LogEntry`.
    2424
    25 If someone has a better proposal or feedback on my proposal I would be happy to hear it.
     25Any feedback is appreciated!
Back to Top