Eloquent Composite Key Support, Never? Why Not?

[andrewalexanderbalogh]

This question has been brought up many times already, on this Discussion board, in Ideas, filed Issues, etc..
Probably since at least 2015 if not earlier from what I've seen.

Why is there no Eloquent Composite Key Support, and will there ever be Eloquent Composite Key Support?

i.e.

• Composite primary key support ideas#1699
• Composite Relationships #33564
• Composite primary keys in Eloquent #45897
• Eloquent should support composite keys #5355 (comment)

Even at present as of the latest Public Release of Laravel, it's pretty much stated that Eloquent Models cannot support table schemas that have Composite Primary Keys
~ https://laravel.com/docs/10.x/eloquent#composite-primary-keys

In terms of Answers as to why Laravel cannot support Composite Keys in Eloquent Models, I've not seen any earnest response as to why it can't and/or won't be done.

As a bare minimum that is what I am requesting here, from someone of Laravel Development team,
just an earnest response as to why it can't be done.

Is it that Composite Keys are considered to be Anti-Pattern, or that use of Composite Keys is bad practice?
Or is it that the underlying Eloquent framework is so rigid such that adding support cannot be done with out significant and extensive refactor?

A bit of background of where I'm coming from; we have a Database with a number of tables having 100's of thousands to millions of entries, of which use Composite Primary Keys for unique identification of the entries.
We try to limit the number indexes and columns to just those as necessary to maintain speedy queries, and to avoid taking up unnecessary disk space.
We have a task at hand where we are migrating an existing project that uses that Database to Laravel.

But as a result of no Composite Key support with Eloquent, the only way we can actually use make use of Eloquent Models with the base Laravel Framework as it sits, is to add a bunch of otherwise redundant Single Primary Keys to the tables, bloating used disk space.

I myself am against this and find it wasteful. I would sooner just work with with the Laravel DB Facade or in the worst case go with plain PDO based queries.

[Sophist-UK]

From a coding perspective, Laravel already often supports e.g. use of lists of strings instead of a single string in these sorts of circumstances, and this would be backwardly compatible i.e. a singleton primary/foreign key would be e.g. "account_id", and a composite primary/foreign key would be e.g. ["branch_no", "account_no", "subaccount_no"].

Without having read all the referenced discussions etc. it does seem to me that the user base does at a minimum deserve an explanation as to why this is not currently supported and (if the case) why it can never be supported - if only to put this issue permanently to rest,

[macropay-solutions]

It is supporting composite keys with some extra work.
We are using composite primary keys in our laravel-lumen-crud-wizard as {relation_name_plural}/12_45 that use Eloquent as it is now.

Note: the separator can be defined to be other character.

[macropay-solutions]

If someone needs composite keys this FREE lib can be used https://github.com/macropay-solutions/laravel-crud-wizard-free | https://packagist.org/packages/macropay-solutions/laravel-crud-wizard-free