[Proposal] Allow customization on Index Keys #12
Description
For a use case I have and I would guess that others might as well, I would need to be able to set a custom key that isn't the same as the actual primary key.
For example, if you had a system (legacy) that had multiple tables of data of similar but different types:
Items that were of types A, B, and C
Table Structures:
ITEM A
id, type,etc
ITEM B
id, type, etc.
etc....
This would end up doing something really funky when adjusting the index on create/update/delete operations since the ids could match but they would actually be 2 different resources.
Although this functionality could be added with some wrapping code like:
pseudo-code:
ITEM_A::search($query)->get()->union(ITEM_B::search($query)->get())
This breaks relevance, and most likely some of the sorting functionality, not to mention the performance hit of multiple round trips, which gets worse the more types there are.
I propose that a new function be added to the ElasticSearchable trait (and maybe at some point to the actual laravel\scout repo's Searchable trait) to enable a variable index key, allowing any sort of keying of data (like composite keys).
As I am actively using this library, I would be more than happy to code this up and submit a PR, just didn't want to do the work if this was something that would be deemed outside the scope/unnecessary.