Formålet med versionsnøglen er optimistisk låsning.
Når den er aktiveret, øges versionsværdien atomisk, hver gang et dokument opdateres.
Dette giver din applikationskode mulighed for at teste, om der er foretaget ændringer mellem en hentning (f.eks. indbringelse af versionsnøgle 42) og en efterfølgende opdatering (det sikres, at versionsværdien stadig er 42). Hvis versionsnøglen har en anden værdi (f.eks. 43, fordi en opdatering er foretaget til dokumentet), kan din applikationskode håndtere den samtidige ændring.
Det samme koncept bruges ofte i relationelle databaser i stedet for pessimistisk låsning, der kan bringe forfærdelig ydeevne. Alle anstændige ORM'er giver sådan en funktion. For eksempel er det pænt beskrevet i ObjectDB-dokumentationen . Det er en objektdatabase implementeret i Java, men det samme koncept gælder.
blogindlægget linket i Behlüls kommentar demonstrerer den optimistiske låsenytte med et konkret eksempel, men kun for arrayændringer, se nedenfor.
På det modsatte er her et simpelt tilfælde, hvor det er ubrugeligt:en brugerprofil, der kan redigeres af sin ejer selv. Her kan du slippe for optimistisk låsning og antage, at den sidste redigering altid vinder.
Så det er kun dig, der ved, om din ansøgning har brug for optimistisk låsning eller ej. Brug case for use case.
Mongoose-situationen er noget speciel.
Optimistisk låsning er kun aktiveret for arrays, fordi det interne lagerformat bruger positionsindeks. Dette er problemet beskrevet af blogindlægget
linket i spørgsmålets kommentar. Jeg fandt forklaringen
angivet i mongoose-orm mailinglisten ret klar:Hvis du har brug for optimistisk låsning til andre felter, skal du klare det selv.
Her er en gist
viser, hvordan man implementerer en genforsøgsstrategi for en add operation. Igen, hvordan du vil håndtere det afhænger af dine brugssager, men det burde være nok til at komme i gang.
Jeg håber, at dette klarer tingene op.
Skål