[Proposal] Allow customization on Index Keys

[ragingdave]

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.

[thomasjsn]

Hey @ragingdave, sorry for the late reply. I can definitely see the need for such user cases.

However; I am currently doing a complete rewrite of how my project interacts with Elasticsearch. I am moving towards getting all data straight from the Elasicsearch index, without looking up the returned ID number with Eloquent.

Still in the evaluation phase, but I like it so far and am continuing down that route. This means that I'm not sure of the future of this package. And thus it might be best for you to do your required changes in a fork, at least for the time being.