meilisearch-php icon indicating copy to clipboard operation
meilisearch-php copied to clipboard

Async calls should be allowed before index is created.

Open tacman opened this issue 9 months ago • 2 comments

I'm struggling with creating an index and dealing with async / sync calls.

https://github.com/orgs/meilisearch/discussions/814#discussioncomment-12402939

This library appears to need the index to be created before most operations can happen, yet the index creation itself is an async call.

It appears that $index->getIndex($uId) return an Indexes object that must exist, but I would like to do create the index and add documents, both queued events.

$client->updateSettings is an async call, so perhaps could be used to bypass the limitation that the index must be created for getIndex() to return an $endpoint of an existing index, but there's very little documentation or examples of making that call.

Am I missing something? I want to run these async tasks:

  • deleteIndex
  • createIndex
  • updateSettings
  • addDocuments

then check all those tasks and when they're all completed, then call fetchInfo and stats. why does getIndex make an API call? It's just getting the API endpoint, don't the operations like addDocuments return a 202 (or 200) even if the index doesn't exist at the time of the call? That is, the request to queue the documents is valid, but that task will fail if the index doesn't exist at the time it's processed, not at the time it's queued.

tacman avatar Mar 05 '25 16:03 tacman

I think I've figured it out. I can submit PRs to help others and my future self with the following huge disconnect:

  $client->getIndex($uId)

makes an API call to get information about an index and returns the endpoint.

  $client->index($uId)

returns an endpoint object without making an API call.

So ->index does not index, it returns an object of class Indexes with is not an array of indexes but rather an API endpoint.

That there are two methods, ->index() and ->getIndex with virtually no documentation.

    public function getRawIndex(string $uid): array
    {
        return $this->index($uid)->fetchRawInfo();
    }

    public function index(string $uid): Indexes
    {
        return new Indexes($this->http, $uid);
    }

    public function getIndex(string $uid): Indexes
    {
        return $this->index($uid)->fetchInfo();
    }

    public function deleteIndex(string $uid): array
    {
        return $this->index($uid)->delete();
    }

sometimes an array returns data, sometimes it returns a task. Yikes! Would you accept a PR that annotates this?

For the next version, in addition to dropping outdated PHP versions, please consider renaming some of the key methods. There's no reason that ->index should return an endpoint but getIndex() makes an API call and also returns an endpoint.

tacman avatar Mar 05 '25 16:03 tacman

Hi @tacman, thanks for opening this issue. I understand your confusion. I think a PR to annotate this behavior would be welcome! 🥰

There's no reason that ->index should return an endpoint but getIndex() makes an API call and also returns an endpoint.

I think the rationale is that ->index allows writing expressive queries by chaining functions, whereas methods prefixed with HTTP verbs actually make requests.

We can argue over this choice, but I don't think we'll be making breaking changes in the immediate future if we can mitigate this with documentation. Thanks for your help!

Strift avatar Mar 09 '25 07:03 Strift