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

searchableAttributes relations are not updated after removal #831

Open
20x-dz opened this issue Oct 13, 2023 · 1 comment
Open

searchableAttributes relations are not updated after removal #831

20x-dz opened this issue Oct 13, 2023 · 1 comment
Labels
needs investigation Needs to take time to understand the issue.

Comments

@20x-dz
Copy link

20x-dz commented Oct 13, 2023

Description
The content of deleted relations that are being used as searchableAttributes are still kept in the index.

Assume the following model (simplified):

Department = {
  title: text
}

To be able to expand the search results I created a SearchSynonm model with a n:m relationship with Department (and other models).

SearchSynonym = {
  text: text,
  "departments": {
    "type": "relation",
    "relation": "manyToMany",
    "target": "api::department.department",
    "inversedBy": "search_synonyms"
  }
}

Department = {
  title: text,
  search_synonyms: {
     "type": "relation",
     "relation": "manyToMany",
     "target": "api::search-synonym.search-synonym",
     "mappedBy": "departments"
  }
}

Searching for a department with a previously created and attached searchSynonym works just fine with the following setting (simplified):

          searchableAttributes: [
            "title",
            "search_synonyms.text",
          ],

But when I remove a synonym from a department the department is still indexed via the previously removed synonym, although the updated entry does not contain any information about the previous relationship (debugged via transformEntry).

I was able to bypass this issue by creating a dynamic attribute in transformEntry (but I think it should also work by using the relationship data directly):

transformEntry({ entry }) {
  const department = {
    ...entry,
    synonyms: entry.search_synonyms.map(synonym => synonym.text)
  };

  return department;
},
settings: {
  searchableAttributes: [
    "title",
    "synonyms",
  ],
}

Updating the index through the strapi settings works as well.

Note: I am fully aware of #424, but this is a different issue, as the indexed model is not being updated accordingly when modified.

Assume the following query for the next two points:

{
  "queries": [
    {
      "indexUid": "department",
      "q": "wort"
    }
  ]
}

Expected behavior
A search should not return entries that had a searchable relationship removed.

{
  "results": [
    {
      "indexUid": "department",
      "hits": [],
      "query": "wort",
      "processingTimeMs": 0,
      "limit": 20,
      "offset": 0,
      "estimatedTotalHits": 0
    }
  ]
}

Current behavior
Data in the index is not being updated.

{
  "results": [
    {
      "indexUid": "department",
      "hits": [
        {
          "title": "Chirurgie",
          "id": 180,
          "search_synonyms": []
        }
      ],
      "query": "wort",
      "processingTimeMs": 0,
      "limit": 20,
      "offset": 0,
      "estimatedTotalHits": 1
    }
  ]
}

Environment (please complete the following information):

  • OS: macOS Ventura 13.6
  • Meilisearch version: 1.3.5 (dockerized)
  • strapi-plugin-meilisearch version: v0.9.2
  • Browser: Chrome 118.0.5993.70, curl 8.1.2 (x86_64-apple-darwin22.0) libcurl/8.1.2 (SecureTransport) LibreSSL/3.3.6 zlib/1.2.11 nghttp2/1.51.0
  • Strapi version: v4.13.7
@brunoocasali brunoocasali added the needs investigation Needs to take time to understand the issue. label Oct 17, 2023
@brunoocasali
Copy link
Member

Hi @20x-dz I read your issue a couple of times. It was hard to decouple it from the similarity of #424.

Could you please provide a reproducible case? It makes it easier to help you with that. A failing test case would be even better. Although our time is very short to do the fixes ourselves, we are a small team that maintains more than 20 different types of integrations, so we rely on the community's power to help improve those repositories.

I'll mark this as needs investigation, so if someone could join and provide a PR, it would be more than amazing.

Hope you will understand, and thank you very much for using Meilisearch ❤️

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
needs investigation Needs to take time to understand the issue.
Projects
None yet
Development

No branches or pull requests

2 participants