mongodb - Is eval that evil? -
i understand eval
locks whole database, can't throughput - have scenario specific transaction involving several documents must isolated.
because transaction not happen , quick (a few updates on indexed queries), thinking of using eval
execute it.
are pitfalls should aware of (i have seen several eval=evil posts without explanation)?
make difference if database part of replica set?
many developers suggest using eval
"evil" obvious security concerns potentially unsanitized javascript code executing within context of mongodb instance. mongodb immune types of injection attacks.
some of performance issues of using javascript in mongodb via eval
command mitigated in version 2.4, muliple javascript operations can execute @ same time (depending on setting of nolock
option). default though, takes global lock (which want apparently).
when eval
being used try perform (acid-like) transactional update several documents, there's 1 primary concern. biggest issue if operations must succeed data in consistent state, developer running risk failure mid-way through operation may result in partially complete update database (like hardware failure example). depending on nature of work being performed, replication settings, etc., data may ok, or may not.
for situations database corruption occur result of partially complete eval
operation, suggest considering alternative schema design , avoiding eval
. that's not wouldn't work 99.9999% of time, it's decide whether it's worth risk.
in case describe, there few options:
{ version: 7, iscurrent: true}
when version 8
document becomes current, example:
- create second document contains current version, atomic set operation. mean reads potentially need read "find current version" document first, followed read of full document.
- use timestamp in place of
boolean
value. find current document based on timestamp (and code clear out fields of older documents if desired once current document has been set)
Comments
Post a Comment