Search query after 1.4.3 cloud upgrade

Hi dear, after updating the new version of the cloud, has anything changed in the search method? Previously I was successfully using search("attribute", [value1, value2]) as specified in the documentation (REST). Now the response from the server is error: "Search queries require exactly one value". Is this a bug? Any solution?

which SDK and which version ( of the SDK ) are you using?

I quickly checked the SDKs for web V10.0.2 https://github.com/appwrite/sdk-for-web/blob/10.2.0/src/query.ts#L24

and V13.0.0 https://github.com/appwrite/sdk-for-web/blob/13.0.0/src/query.ts#L42

The value for a search query has always been a single string rather than a list 🤔

I use Appwrite via HTTP requests without SDK, using a direct REST API call with queries[] parameter something like: https://cloud.appwrite.io/v1/databases/{databaseId}/collections/{collectionId}/documents?queries[]=search("attribute", [value1, value2])

Before the update this was functional, that's for sure. The same loss is when calling equal("attribute", [value ...]).

This functionality is described in the REST API documentation here: https://appwrite.io/docs/rest

In Appgyver, where I use it, I don't have better API consumption or loop programming capabilities, so this functionality is essential for me. (and is one of the important motivations for switching from Firebase to Appwrite) 🤨

To get things working, can you pass the values in a single string instead of an array?

@Steven No, it doesn't work that way, the values in the array were originally evaluated as or. That was elegant and simple. This is not the solution. Can someone from the core team working on the rest api take a look at this? @Meldiron @Christy Jacob

Passing the values in a single string breaks the logic of all rest api calls according to the above documentation (and breaks my app). https://appwrite.io/docs/rest

It is mentioned as an array parameter. select select([attribute]) equal equal("attribute", [value]) search("attribute", [value]) ...

It should still be or. What exactly are you passing?

The books have genres e.g. Genre: young adult, for girls, romance, literary fiction, ... Genre: young adult, for boys, action, literary fiction, ... Genre: young adult, for boys, spy, non fiction, ... I want to construct a query 'all books for girls and boys', something like: search("genre", ["for girls", "for boys"]) or 'fiction for boys': search("genre", ["for boys", "literary fiction"]) I've tried replacing array with string (looks ok), I still can't cope with two words separated with space ( or ...?) search("genre", "for boys, literary fiction")

So the query in the network request should look something like search("genre", ["\"for girls\" \"fiction\""]

No, query with one keyword is ok but response with two search strings is empty.

Hi, I've experimented with different formats and it only works with single-word comma-separated arguments search("genres", ["boys,girls"]) - with or without square brackets, both. I can already solve this somehow (slug instead of separate words). But in all this experimenting, I tried reindexing the database and got stuck somewhere. (delete index) 😵‍💫

Any help with stucked index?

What's your project id?

@Steven We can't solve this?

actually, can you try with 2 backslashes? Here's an example of my test:

were these processing when you deleted them?

1.) I solved the stacked index by deleting the current collection and creating a new one. All operations are very slow lately and often end with error 500 (clearly beta).

2.) I found that the search query uses the MATCH AGAINST construct, so it doesn't matter if square brackets are used or not (pure is without). BOOLEAN gives other options. Validator in search query was changed in the last version: public function isValid($value): bool { ... case Query::TYPE_GREATER_EQUAL: case Query::TYPE_SEARCH: case Query::TYPE_STARTS_WITH: case Query::TYPE_ENDS_WITH: if (count($value->getValues()) != 1) { $this->message = \ucfirst($method) . ' queries require exactly one value.'; return false; } ... this was not before. That's why all my older REST API calls don't work: search("genre", ["for boys", "literary fiction"]) evaluates to an array. If it was delivered to AGAINST like this it would probably work anyway.

Right, I was suggesting to pass 1 value

@Steven could you please consider having someone remove this array check on the full-text search query? It's useless and doesn't allow to submit a correct full-text query with multiple words. As described in the documentation for fulltext search, e.g. here: https://mariadb.com/kb/en/full-text-index-overview/ ... Multiple words: SELECT * FROM ft_myisam WHERE MATCH(copy) AGAINST('wicked,witch');

Anything enclosed in double quotes is taken as a whole (so you can compare phrases, for example). ... And so it is correct to send a query in the format: search("genre", ["books for boys", "literary fiction"])

this would be equivalent to:

"\"books for boys\" \"literary fiction\""

or maybe

"\\"books for boys\\" \\"literary fiction\\""

depending on how escaping works