Should we use uid in task body ?

[bidoubiwa]

⚠️ Update: After giving it more thought, I think the way it is currently is better (with uid in both). I think I'm biased because of how I used updateId in the past. Because I cannot delete this discussion I leave it open :)

archive

I have a hard time when coding to see the difference between uid of an index and uid of a task. Inside the task the uid of an index is called indexUid but when creating an index it is called uid.

Maybe we can consider to avoid any confusion on what the uid represents to name them the same everywhere?
indexUid in all contexts and taskUid in the tasks body.

Task body:

    {
      uid: 8069,
      indexUid: 'movies_test',
      status: 'enqueued',
      type: 'indexCreation',
      enqueuedAt: '2021-12-23T13:54:33.258405436Z'
    }

Index body:

   {
      uid: 'movies_test',
      name: 'movies_test',
      createdAt: '2021-12-23T13:55:45.327320984Z',
      updatedAt: '2021-12-23T13:55:45.327320984Z',
      primaryKey: null
    }

This is why I originally brought up the discussion:

const uid = "movies"
const { uid: taskUid } = client.createIndex(uid)

or

const indexUid = "movies"
const { uid } = client.createIndex(indexUid)

If someone enter a source code and see a uid variable running in the wild, they wont be able to know for sure which one of the index or task uid it is.

BUT! it does create consistency and can be more intuitive for the user. I may be completely biased because of my previous usage of meilisearch !!

[alallema]

I agree with @bidoubiwa. I think that if we keep the same identifier uid, it must be well specified in the documentation because it was quite confusing for me too.
But in a other hands it' goods to have consistency with terms in différents response.

[gmourier]

Hi @bidoubiwa and @alallema! Thanks for the feedback! 😇

To explain the logic from a pure format and data organization point of view when designing an API, here is what I think.

On this route, the API handle the tasks resource which has an uid. It seems logical to have an indexUid to represent the index resource linked to the task.

It brings some advantages:

• Using uid is a consistency on each API resource to represent the unique identifier of the direct handled resource. (As you said it after! 😇)
• No need to prefix uid every time by the direct handled resource name.
• Gain some bandwidth/size on big responses.

However, something we could do is to use a nested object representation and transform indexUid in this way.

{
    "uid": 1,
    "index": {
        "uid": "movies"
    },
    ...
}

There is no real immediate interest in returning more information about the index related to the task other than its uid but it could be a strict convention as we decided to do for error which is a sub-object of task. In my opinion, there are direct advantages to having an error nested object. (Readability, network usage).

[gmourier]

The uid representing a task will be renamed taskUid to give more context to an asynchronous response.

Specified in meilisearch/specifications#144.

Locking the discussion.