[danafon]

🤖 AI (if applicable)

• The content of this PR was partly or fully generated using AI (N/A)

The PR addresses the issue: #710

Problems addressed / decisions made:

• for now, the pr contains only the backend part - hence it's a draft
• separate endpoint instead of query parameter in LIST endpoint
• the search is based on iLike function, with a room for modification (if indexes are integrated)
• query is built using join, the alternative of exist was considered but rejected - it is not supported by server v35
• second commit contains the DI modification, so the integration of other search methodology will be limited by addition of another implementation of the search interface. If this is considered over-engineering, the commit could be reverted

[julien-nc]

Thanks for the nice PR and explanations.

The second commit is indeed a bit overkill. I don't think we want to decouple the search logic and allow to plug multiple ones. This search feature is used by the assistant itself, we don't want to allow other apps to register an alternative search logic anytime soon.

If you have time you can implement a small frontend part which uses the new search endpoint.

the alternative of exist was considered but rejected

Which alternative?

if indexes are integrated

Nice to mention indexes, there might indeed be a lot of messages in this table. How about adding an index that will be used by the search query?

[danafon]

Hi @julien-nc

1. I reverted the DI commit
2. Added the frontend part in the separate commit
3. The alternatives question: I meant that I wanted to create "WHERE EXISTS" query but ended up using "JOIN"
4. Are we talking about a full-text index within the database query or the external search index (like elastic search)?

[julien-nc]

Thank you for the followup changes.

4. I'm talking about adding a database table index to improve the average search query performance.
   We can see that later.