Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Selected collections to index for Meilisearch reset on reboot #695

Open
sjorsjes opened this issue Apr 25, 2023 · 4 comments
Open

Selected collections to index for Meilisearch reset on reboot #695

sjorsjes opened this issue Apr 25, 2023 · 4 comments
Labels
enhancement New feature or request

Comments

@sjorsjes
Copy link

Description
I run Meilisearch and Strapi in a kubernetes environment. When Meilisearch and Strapi are running I can select the collections to index and everything is passed to Meilisearch and when I check the UI everything is indexed.

At the moment I have no volume set up for Meilisearch so when I reboot the container all indexes are gone. This normally only happens when I update the Meilisearch container and not really a problem for my situation.

But when this happens, in Strapi, not a single collection is selected for Indexing anymore and I have to manually turn them on again.

Expected behavior
I would expect Strapi to remember the collections I want indexed and reapply the index (cron job?).

Current behavior
Strapi resets all collections from being indexed.

Environment (please complete the following information):

  • OS: Kubernetes
  • Meilisearch version: 1.1.1.
  • strapi-plugin-meilisearch version: 0.9.1
  • Browser: any browser
  • Strapi version: 4.9.2
@bidoubiwa
Copy link
Contributor

Hey @sjorsjes

To confirm I understood your problem correctly. Sometimes you re-run your strapi without the Meilisearch running, which removes the checked boxes. Then, once you run Meilisearch again and relaunch Strapi, you expect the previously added collections to be re-indexed in Meilisearch?

The way it works today is as follows.
When you select an Index on the plugin page, It will:

  • Add all the entries of your collection to meilisearch
  • Create a listener on that collection
  • Add the name of the index in the store of strapi (in the db).

Whenever your re-run strapi (build or dev), the bootstrap files fetches all existing indexes in Meilisearch and all index names that are stored in Strapi. It compares the list and remove from the store every index that is not found in Meilisearch. For the ones that are still there, we add them to the collections we are listening to.

What you are suggesting is that on Strapi bootstrap, we take the list of indexes from the store, and instead of removing the ones missing in Meilisearch, we re-index them?

@bidoubiwa bidoubiwa added the enhancement New feature or request label Apr 27, 2023
@sjorsjes
Copy link
Author

sjorsjes commented May 8, 2023

Sorry for the late response, I was on holiday.

Whenever your re-run strapi (build or dev), the bootstrap files fetches all existing indexes in Meilisearch and all index names that are stored in Strapi. It compares the list and remove from the store every index that is not found in Meilisearch. For the ones that are still there, we add them to the collections we are listening to.

That explains why none of my collections are selected anymore after a reboot from Meilisearch (because all indexes are gone).

What you are suggesting is that on Strapi bootstrap, we take the list of indexes from the store, and instead of removing the ones missing in Meilisearch, we re-index them?

Yes! I would not use Meilisearch as a reference to check what collections should be indexed because it can happen that all indexes are gone.

@brunoocasali
Copy link
Member

Hi @sjorsjes, just to inform you, @bidoubiwa is on holiday 🌴. You can expect a reply next week! 🎉

@bidoubiwa
Copy link
Contributor

Hey @sjorsjes,

Lets add this behavior!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

3 participants