Generic PK field that references real PK field

[abondar]

Currently tortoise can work normally if your PK is int field named id. It should instead work with pk field like in django, that references real PK field that can have various types and names

[monospacedmagic]

This issue is indeed very important as it prevents people from normalizing their databases in a sane way. This would not be too much of an issue if we could just easily migrate the database structure once this issue is fixed and we changed our database structure, however, migration is also not yet implemented and seems to be a far more complex issue than this.

While you're at it, you could add support for composite primary keys as well. The lack of that feature already made it difficult to properly normalize tables in Django, so it would be especially nice to have it here. 🙂

[grigi]

Composite primary keys is a touchy subject, but they have their use cases.

I for one, was actually thankful that Django imposed the non-composite rule on me, and it forced me to come up with a better design. But there is still cases where a composite key is the best solution.

The other thing is, that depending on the database (e.g. MySQL), having a autonumber as the primary key is essentially free, as it you have a rowid if you want it or not. Which means that non-autonumber primary keys have a significant disadvantage out of the gate.

But let that not discourage us. This is something that I really wanted to get done, and even labeled it as a pre-requisite for v1.0 (Which is the first planned stable release, with all the formalized baggage that implies)

[monospacedmagic]

Thank you!

In my particular use case, I am building a library, and a UserGroup's name is already a unique identifier, so it would make sense to make it the primary key. In another use case, I want to set the foreign keys of a through table for a ManyToManyField as primary keys because the pair of them uniquely identifies a database tuple already, no need for an ID. On top of the no need for an ID, it's also easier for library users to create objects of that through model because they can know the values of the two foreign primary keys, but they cannot know the auto-generated IDs.

I hope that makes sense and clarifies why I want/need this as much as I do. :)