Changes regarding Meilisearch v0.26.0

[curquiza]

This issue gathers the changes related to the v0.26.0 of Meilisearch that will impact the integrations.

Release date: 14/03/2022

The whole milestones of v0.26.0 here: https://github.com/meilisearch/meilisearch/milestones/27

---

New flag behavior

Related to meilisearch/meilisearch#2097

It means every --no-analytics=true are now --no-analytics

This impacts every integration in our

• CIs
• examples in CONTRIBUTING.md
• some docker-compose files if they exist

⚠️ We will try to automate most part of the work with octopus (internal tool), but please, check no --analytics=true has been forgotten.

New dump behavior

Related to

• this issue New dump behavior meilisearch#2087
• this spec: Dumps specifications#105

Some changes impact meilisearch-migration.

Two changes in v0.26.0:

• When importing a dump using --import-dump if a database already exists, an error message will be thrown on the CLI.
• Similar to the behavior of the snapshot feature. The flags --ignore-dump-if-db-exists and --ignore-missing-dump are added. -> does not impact meilisearch-migration if I'm correct.

Tenant tokens

Related to:

• this issue: Tenant Tokens (Multi-Tenant indexes) meilisearch#1991
• this spec: Tenant Token specifications#89

We have to add a generateToken method to every SDK following the spec requirement to make it easy to generate the token for the future search of the user.

Some instruction

• for the JS SDK -> only implementing for Node.js, not for front-end.
• As first, try not to use any other library, but if it's not possible, use the most appropriate one.
• Maybe this will need discussion to find the most user-friendly way to provide the method. Should stay doable regarding the deadline (4 weeks during the pre-release).

🔥 We should add tests 🔥

---

TODO:
The PR linked below should be merged

[brunoocasali]

@brunoocasali, @bidoubiwa, and @alallema decided in an internal meeting:

Regarding the token generation, we should have a method like this:

client.generateTenantToken(Object searchRules, DateTime expiresAt:?, String apiKey:?) => String

ps: expiresAt and apiKey are named/keyword params.

If the language doesn't support named parameters it should use:

client.generateTenantToken(Object searchRules, Object options?) => String

The implementation of the token generation should be done without a library but having one is not "prohibited".
When the apiKey is not present we will use the current apiKey from the MeiliSearchClient instance called the generateTenantToken method.

We also opted to not ask as a parameter the hashing algorithm, we will support out-of-box only HS256. If users want more options, they could raise issues for us.

We will not add too complex validations regarding the searchRules, because they were already defined and maintained inside of the core engine, so it doesn't make sense to replicate this logic inside of each SDK.
To help users with possible errors, we will ask for the core team to improve the search errors when they were related to the tenant token.

[brunoocasali]

Follow up about validations:

Since we will not be able to cover all the aspects regarding the validations we still need to add some checks in the generateTenantToken implementation:

• expiresAt: should be in the future, should be in UTC, should be a date/time object, could be null.
• searchRules: should be a array, hash, hashmap or object.
• apiKey: should be a string, the parameter could be null since the client has the apiKey already defined.

FYI: @meilisearch/integration-team

[alallema]

• searchRules: should be a string, array or hash, hashmap, object, should not be a null value.

I don't think searchRules could be a string no?

[bidoubiwa]

searchRules: should be a array or hash, hashmap, object, should not be a null value.

Iike @alallema said. While it is true that it should not be a null, it also should not an integer or boolean etc..
Maybe we should removed the should not be a null and only check if searchRules is the following

array or hash, hashmap, object

[alallema]

Iike @alallema said. While it is true that it should not be a null, it also should not an integer or boolean etc..
Maybe we should removed the should not be a null and only check if searchRules is the following

I agree with @bidoubiwa, I think it would be nice to test the type but depending on the language we can always check if the searchRules are not null in case.

[brunoocasali]

@alallema @bidoubiwa updated!

[brunoocasali]

Congratulations @meilisearch/integration-team we made it! 🎉 🎉

🎶 🎵 🎶 🎵 WE ARE THE CHAMPIONS!! 🎶 🎵 🎶 🎵