Update Index API for Meilisearch v.28

[alallema]

Pull Request

Related to: meilisearch/meilisearch#2373

What does this PR do?

Changes

• client.getIndexes() accept pagination metadata, added limit (default: 20), offset (default: 0), total
• Wrap the indexes objects in a Results object
• Remove client.getRawIndex() method
• client.getRawIndexes() method return a String
• Creation of IndexesQuery class
• Rename the methods of the "IndexesHandler" to match the name of the Client methods

    client.getIndexes()

returns for example

com.meilisearch.sdk.model.Results@2a742aa2

    client.getRawIndexes()

returns for example

{"results":[],"offset":0,"limit":20,"total":0}

[brunoocasali]

Nice change! 👯

[bidoubiwa]

I don't see the updateIndex method.

Can you also change the name of the PR with more context? For example

Update Index API for Meilisearch v.28

[alallema]

I don't see the updateIndex method.

Can you also change the name of the PR with more context? For example

Update Index API for Meilisearch v.28

It's on line 151 on Client file and this method is called updatePrimaryKey on the IndexesHandler file because it updates the primary key.

[bidoubiwa]

It could be nice to use IndexesQuery everywhere so that we only hardcode /indexes in toQuery. Nonetheless, maybe it is worth creating an issue for that change to avoid making this PR more complex

[alallema]

We can indeed do this but it means creating a new function that will require resources and complicate the general call such as:
return httpClient.get("/indexes", Results.class, Index.class);
will became:
return httpClient.get(new IndexesQuery().toQuery(), Results.class, Index.class);
Not sure it worth it but we can also just create a variable in the IndexesHandler class:
String indexesPath = "/indexes";

[bidoubiwa]

I prefer the second option for consistency, but you are maybe right. You can ignore this for the moment but I would like the opinion of @brunoocasali on that

[alallema]

Me too !

[brunoocasali]

My initial conception around IndexesQuery, KeysQuery, and so on, where to handle query parameters. If we are very strict, we can say that the /indexes path is related to the URL, not the query parameters, so it shouldn't be inside.

In any case, I don't think /indexes should be treated as handled inside of IndexesQuery, but if we use a private constant inside of IndexesHandler is enough.

If the path change in the future, we will have two places to change the tests, IndexesQuery and IndexesHandler.

[bidoubiwa]

LGTM 🔥🔥🔥🔥🔥

Nice work ✨✨✨✨