mongodb - Mongoose versioning: when is it safe to disable it? -
from docs:
the versionkey property set on each document when first created mongoose. keys value contains internal revision of document. name of document property configurable. default __v. if conflicts application can configure such:
[...]
document versioning can disabled setting versionkey false. not disable versioning unless know doing.
but i'm curious, in cases should safe disable feature?
the version key purpose optimistic locking.
when enabled, version value atomically incremented whenever document updated.
this allow application code test if changes have been made between fetch (bringing in version key 42 example) , consequent update (ensuring version value still 42). if version key has different value (eg. 43 because update has been made document), application code can handle concurrent modification.
the same concept used in relational databases instead of pessimistic locking can bring horrible performance. descent orms provide such feature. example it's nicely described in objectdb documentation. it's object database implemented in java same concept applies.
the blog post linked in behlül's comment demonstrate optimistic locking usefulness concrete example, arrays changes, see below.
on opposite, here simple case useless: user profile can edited owner ownly. here can rid of optimistic locking , assume last edit wins.
so, know if application need optimistic locking or not. use case use case.
the mongoose situation special.
optimistic locking enabled arrays because internal storage format use positional index. issue described blog post linked in question's comment. found explanation given in mongoose-orm
mailing list pretty clear: if need optimistic locking other fields, need handle yourself.
here gist showing how implement retry strategy add
operation. again, how want handle depends on use cases should enough started.
i hope clears things up.
cheers
Comments
Post a Comment