Changes due to the implicit index creation

[curquiza]

Related to meilisearch/integration-guides#48

📣 So sorry for all the "pollution" changes in the code-base comments. In order to help you with this huge PR, here is the list of changes you have to check:

• The Getting Started changed as described in the main issue.
• get_index() does an HTTP call and is not the main method to use anymore.
• Add the index() method
• Add tests for index() method
• Update get_or_create_index with the new way of using index()
• Rename Index.get_indexes into Index.list_all to avoid repetition. This method is not provided in the docs so this is mostly an internal usage.
• Add a primary_key attribute in Index class. This attribute is updated when an HTTP call to the index is done (creation, update, or fetch the info). The attribute is obviously not up-to-date when using the index() method. See the limitation section in the main issue.
• The info() method is not documented anymore because get_index does the job now. I renamed it to fetch_info() to make the HTTP call explicit. Since it's not documented, its usage is mostly internal, but I also updated the tests accordingly, so this method is still well tested.
• Remove get_index from the Index class. This method is not used internally, and if the users would use it, they would have to write Index.get_index('movies') which is not really intuitive. The right usage is client.get_index('movies') or client.index('movies').fetch_info().
• Change code-samples.

⚠️ the index.py changes might be not visible if you don't click on load diff:

Good luck ♥️

[bidoubiwa]

Rename Index.get_indexes into Index.list_all to avoid repetition. This method is not provided in the docs so this is mostly an internal usage.

I'm not sure I understand this point. Is get_indexes not a Client method instead of an Index method? Do we agree that this is the function that gets all indexes?

I do not remember we talked about that change. Also, it should be a Client method I think.

The info() method is not documented anymore because get_index does the job now. I renamed it to fetch_info() to make the HTTP call explicit. Since it's not documented, its usage is mostly internal, but I also updated the tests accordingly, so this method is still well tested.

Does this mean, get_index and fetch_info() are the same?

Nevermind, I understood it with the bullet point after this one

[curquiza]

I'm not sure I understand this point. Is get_indexes not a Client method instead of an Index method? Do we agree that this is the function that gets all indexes?

Before my change there were 2 methods get_indexes (and the SDK python is the only one that provides this):

• one in Client class as an instance-method, so you called it client.get_indexes(). client is an instance of Client.
• one in Index class as a class-method so you called it Index.get_indexes(). Index is the class, not an instance.

The first one (in Client) calls the second one (in Index). I changed the name of the second one to list_all. Because Index.get_indexes was redundant.
The get_indexes method in the client (the first point) is still available of course. You still can use it as before (see the tests). I just renamed an internal method.

[bidoubiwa]

I don't think Index.list_all should be kept. You're inside a specific Index, not in the scope of all indexes. If later on, we create authorizations with permission on only one given index you should not have some methods that are not related to that specific index.
But even further, it's just not the same scope and it seems weird that this method exists inside Index.
If you like it, we can keep it of course, but I feel like we should not.

[curquiza]

I don't think Index.list_all should be kept. You're inside a specific Index, not in the scope of all indexes. If later on, we create authorizations with permission on only one given index you should not have some methods that are not related to that specific index.
But even further, it's just not the same scope and it seems weird that this method exists inside Index.
If you like it, we can keep it of course, but I feel like we should not.

I completely agree, but because it was here, I thought there was an implementation reason and I didn't want to "impose" another restructuration change 😂 Rename it was the best compromise I found because I don't like this function either. But I would be glad to remove it if both of you agree. @eskombro ?

[curquiza]

It was a mistake to make such a big PR with changes that are not related to the PR (comments in the code + code restructuration). My bad!

The git history of the branch and the conversation history of this PR are not clear anymore, I will open 3 new distinct ones:

• changes due to implicit index creation
• code restructuration
• update the comments in code-base

Sorry for this inconvenience.
Closing this PR in favor of #175