Rename "primary key"

[dichotommy]

IMO it's confusing to have something called "primary key" that is not at all related to API keys, authorization, or the keys endpoint. It would at least make sense if we used "key" often in the sense of "key: value", but at least on the docs we currently prefer the term "attribute" (i.e. "attribute: value").

I would suggest "primary field" as a replacement name.

[gmourier]

Thanks @dichotommy ! PrimaryKey is a massively known field thanks to the SQL systems.

Since we are not a SQL db, we could decide to deviate from it in order to be clearer about its usage, why not call it documentIdentifier since it's literally a document identifier?

[curquiza]

I'm not strongly against the documentIdentifier idea, but I have some concerns

• I'm a little bit picky maybe, but for me, the document identifier meaning is not the name of the field (so the key), but the value itself. I mean, for { "id": "1"}, 1 is the document identifier, and id is the primary key. So for me documentIdentifier is a little bit wrong, since it's related to the value and not the key.
• As guigui said, primary key is an already widely used term in the SQL world.
• The last but not the least, and not related to documentIdentifier but to every change regarding the primaryKey name: this change is a huge breaking for the users, so if we change it, we have to ensure it's worth it, otherwise it's a big user pain point for a not-really-big impact.

Saying this, if everyone is ok with this change, I will follow you 😇 As I said, despite my arguments, I'm not strongly against this change. My main concern is maybe about the 3rd point (the real impact of this huge breaking)

[gmourier]

Thanks @curquiza !

@dichotommy, I think it's complicated for the reason that it's a huge breaking change that would break all the data import scripts that would use primaryKey.

Personally, I'm not bothered by primaryKey. For me it's equivocal but I used a lot of SQL database in the past so I may biased.

The advantage of this term is that we'll have a lot of users with a SQL database wanting to add a search engine to their stack because of the limitations of SQL. At that time, the term primaryKey will help them more than any other term, probably.

But since we are working on v0.28 to make the last big breaking changes, if we have to go there let's go, we just have to find the right term.

Have you had any feedback from users on your side @meilisearch/docs-team about that term? It could help to take a decision about this one. I've seen 0 direct feedback about that since I arrived except internally.

[dichotommy]

for me documentIdentifier is a little bit wrong, since it's related to the value and not the key.

I agree with this 💯

Have you had any feedback from users on your side https://github.com/orgs/meilisearch/teams/docs-team about that term?

Nope, I don't believe we have had any feedback about it. Given that and the cost of changing the name, it sounds like it's not worth changing.

Thanks for your replies @curquiza and @gmourier 😸

[guimachiavelli]

I have to be honest and say I really don't think that confusion between key (as in key-value pair) and key (as in security key) is a good motivation for changing "primary key" to something else. I'm not the programmiest of programmers and even I have never found this point to be particularly confusing.

Also, we're talking about primary key as in the attribute whose value uniquely identifies a document, correct? In the current Documents guide, we often speak of a "primary field" that contains a "primary key" and a "value." I do find that a bit clunky and difficult to write around, but I'm unconvinced changing primaryKey to primaryField would help us. I could see primaryAttribute as making more sense, but, reading @gmourier and @curquiza's comments, seems a lot of problem for marginal gains.

[curquiza]

Checked with @gmourier, after reading your comments (thanks a lot for these), we decided not to change the primary key name in v0.28.0. Too much impactful breaking for a low user-experience impact.
Thanks again for your participation.

The discussion is not close forever, you can keep discussing. It's only closed for v0.28.0 so probably (99% sure) v1