Syftet med versionsnyckeln är optimistisk låsning.
När det är aktiverat, ökas versionsvärdet atomiskt när ett dokument uppdateras.
Detta gör det möjligt för din applikationskod att testa om ändringar har gjorts mellan en hämtning (t.ex. ta in versionsnyckel 42) och en efterföljande uppdatering (se till att versionsvärdet fortfarande är 42). Om versionsnyckeln har ett annat värde (t.ex. 43 eftersom en uppdatering har gjorts av dokumentet), kan din applikationskod hantera den samtidiga ändringen.
Samma koncept används ofta i relationsdatabaser istället för pessimistisk låsning som kan ge hemska prestanda. Alla anständiga ORM tillhandahåller en sådan funktion. Det är till exempel fint beskrivet i ObjectDB-dokumentationen . Det är en objektdatabas implementerad i Java men samma koncept gäller.
blogginlägget länkade i Behlüls kommentar visar den optimistiska låsningsnyttan med ett konkret exempel, men bara för arrayförändringar, se nedan.
På motsatsen, här är ett enkelt fall där det är värdelöst:en användarprofil som kan redigeras av sin ägare själv. Här kan du bli av med optimistisk låsning och anta att den sista redigeringen alltid vinner.
Så det är bara du som vet om din ansökan behöver optimistisk låsning eller inte. Använd fall för användning fall.
Mongoose situationen är något speciell.
Optimistisk låsning är endast aktiverad för arrayer eftersom det interna lagringsformatet använder positionsindex. Detta är problemet som beskrivs av blogginlägget
länkas i frågans kommentar. Jag hittade förklaringen
ges i mongoose-orm e-postlistan ganska tydlig:om du behöver optimistisk låsning för andra fält måste du hantera det själv.
Här är en sak
visar hur man implementerar en strategi för ett nytt försök för en add drift. Återigen, hur du vill hantera det beror på dina användningsfall men det borde räcka för att du ska komma igång.
Jag hoppas att det här klarar upp saker och ting.
Skål