Use a wildcard to add all remaining fields to searchableAttributes while still weighting some fields more than others

[bebert64]

Unless I'm mistaken, there are only two ways to set searchableAttributes as of now : you either add all of them using a wildcard anywhere in the array, giving all your fields the same weight, or you explicitly name the ones you want to prioritize, but you exclude any field not mentioned.
The problem in my case is that from one document to the next, some fields are commons and really important, and I would like to prioritize, and the other fields vary, so I can't list them explicitly, but I'd still like to be able to search them.
The idea would be to send an array ["my_attr_1", "my_attr_2", "*"], and matches on fields 1 and 2 would pop up in my results before the other ones, but I'd still get results matching any other field.

I looked quickly at the code, and it does not seem trivial to implement 😢 but I would be willing to work on it with some guidance. Let me know what you think.

(It feels like this feature might be related, but it felt different enough for a new discussion. Please let me know if you'd prefer to merge the two features proposal).

[macraig]

Hi @bebert64 , I can definitely see how that feature would be handy in your case. As it stands, you're correct that you either need to use a wildcard for all fields or explicitly list the ones you want to prioritize.

One possible approach, even though you mentioned it may not work for you, is to list all the fields in searchableAttributes. This way, you could still prioritize certain fields like "my_attr_1" and "my_attr_2" while making sure the rest are included, even if they're given a lower priority.

Could you clarify a bit more on why listing them explicitly isn't feasible for your case? It might help us explore potential workarounds.

[bebert64]

Hi. The documents we are sending to Meilisearch are the json serialization of a complex nested rust struct. I guess listing all fields explicitly is technically feasible, but very impractical. Listing them once would require some amount of work but is doable. The problem starts when the struct evolves.
As you know, there isn't really any introspection per say in rust, so automatically retrieving the list of fields is complex. We could use some derive macro to do it, but unfortunately, that struct is generated by some external codegen that we can't modify, so that's not an option either.
For now, we've decided to add new fields manually to the searchableAttributes list when we're modifying the struct. But that process is very error prone, and we would have preferred not to need it.

Just to be complete: we are (at least) testing that the fields included in the searchableAttribute list do exist on the struct. So if a field is removed or renamed, we are confident the list will reflect that as well. The issue really only concerns new fields.

I hope that's a bit clearer 😄

[macraig]

Thanks for sharing the details of your use case! I understand how tricky it can be to keep searchableAttributes in sync, especially with complex Rust structs that are constantly evolving. Manually updating the list is definitely not ideal and can be error-prone.

While this isn't something we have planned at the moment, I understand how useful it could be in situations like yours. I'll keep this in mind if we decide to rework how searchableAttributes are handled in the future. In the meantime, I'll leave this discussion open for others to upvote and chime in with their thoughts.