Changes between Initial Version and Version 1 of Ticket #35956, comment 4


Ignore:
Timestamp:
Dec 28, 2024, 10:10:32 AM (11 days ago)
Author:
Csirmaz Bendegúz

Legend:

Unmodified
Added
Removed
Modified

  • Ticket #35956, comment 4

    initial v1  
    11Replying to [comment:2 Mariusz Felisiak]:
    2 > Replying to [ticket:35956 Csirmaz Bendegúz]:
    3 > > My proposal is to add 2 parameters to `ForeignKey`: `from_fields` and `to_fields`.
    4 >
    52> Do we need these parameters? `CompositePrimaryKey` is always a primary key so its fields should be detected automatically, IMO, the following example should work:
    63> {{{#!python
    … …  
    1613
    1714The issue with this example is `RefRelease` must have 2 fields matching the `CompositePrimaryKey` (an `IntegerField()` and a `CharField(max_length=20)`).
    18 So `release` would need to create 2 fields implicitly and I'm not sure if this would be a good direction?
    19 We should allow sharing fields between composite foreign keys, for example in a multitenant app, the `tenant_id` should be shared between multiple composite foreign keys.
     15
     16So `release` would need to create 2 fields ''implicitly'' and I think that's too restrictive.
     17
     18We should allow **sharing fields between composite foreign keys**.
     19
     20For example, in a multi-tenant app where each model has a `CompositePrimaryKey("tenant_id", "id")`, the `tenant_id` field should be shared between composite foreign keys.
     21
    2022Let me know what you think, I'm happy to consider any alternatives.
Back to Top