Where is the _id generated (and checked)?
Database action insert now seems to be a synchronous return of _id immediately after insert, so no callback is needed here.
The question is where the _id is generated (and checked) as this appears to be a fast synchronous action done on miniMongo, but there is no complete list of the _id of a specific collection, so it is possible that miniMongo check if the _id is duplicated or not?
source to share
When used Collection.insert
on the client, it _id
is generated on the client with a random uuid algorithm , hence seemingly perfect client side latency compensation.
Collection.insert
implemented as a special case Meteor.method
, we know that at the same time the client simulation is launched on the client, the corresponding server operation is launched, the client document is sent to the server along with its locally generated one _id
.
The server has a validation to make sure the _id
correct (truly unique) one and the server confirms the correct insert back to the client.
If the client generated _id
was not unique after all, then the insert will fail with a "recurring key error" (this can happen as much as 0.001% of the time - the probability is even lower and you will have to resubmit your client form or whatever) ...
To answer specifically your question, _id
may be generated in the browser in the event of a client-side insert, but ultimately its validity is checked on the server.
EDIT: Originally it was assumed that Meteor is trying to recover the duplicate key error and create a new key to avoid duplicity and propagate it to the client, I checked the use case and found I was wrong, thanks @Tom Freudenberg for pointing this out.
source to share