* Changes since last PR: use LogicalDataSource for Methods::StateRegistrationCallback instead of TRI_voc_cid_t to avoid unnecessary lookups
* backport: address cluster LogicalDataSource resolution failure
* fix some deadlocks found by evil lock manager (tm)
* fix duplicate lock
* fix indentation
* ensure proper lock dependencies
* fix lock acquisition
* removed useless comment
* do not lock twice
* create either a V8 transaction context or a standalone transaction context, depending on if we are called from within V8 or not
* AQL micro optimizations
* use explicit constructor
* only use V8DealerFeature's ConditionLocker for acquiring a free V8 context
entering and exiting the selected context is then done later on without having to hold the ConditionLocker
* remove some recursive locks
* Disable custom deadlock detection when Thread Sanitizer is enabled
* Changing ifdef's
* grr
* broke gcc
* Using atomic for ApplicationServer::_server
* fix premature unlock
* add some asserts
* honor collection locking in cluster
* yet one more lock fix
* removed assertion
* some more bugfixes
* Fixing assert
(cherry picked from commit 1155df173bfb67303077fbe04ee8d909517bfd21)
* remove some non-unused V8 persistents
* do not throw that many bogus assertions
* do not rely on server role being defined
* slightly better debug output for V8 context debugging
* fix collection ids in inventory response
* simplify bootstrap a bit
* slightly better error handling
* make elapsed time a queryable value
* use less memory for stub collections
* added assertions that will always make sense
* added assertions
* do not garbage-collect while waiting
* less copying of parameters
* do not show "load indexes into memory" buttons for mmfiles engine
as all indexes are in memory anyway
* when a collection is truncated via the web interface, flush the WAL and rotate all active journals
this will make close all open journals on leader and followers and make them subject to compaction opportunities
* fix invalid server id values being passed from web interface to backend
* introduce afterTruncate method for indexes
* added test case for issue #3447
* updated CHANGELOG
* don't warn about replicationFactor for system collections
* check that the queries actually use the geo index and not some other index
* properly report error in web interface
* fix some internals checks that made truncate fail for bigger collections in maintainer mode
* also run a compact() operation after a serious truncate
in order to make iteration over the truncated range much faster
when the collection is next accessed
* increase default maximum number of V8 contexts to at least 16
* removed delete call
* cleanup
* lower cpu activity of log thread too
* fix log messages
* do not enter threads into unordered_set, as it is unneeded
* do not compile in calls to disabled plan cache
* moved AQL regex cache from thread local variables to a class of its own
* more sensible thread creation and destruction
An invalid rev should lead to a 1200 ("conflict") error rather than a
1239 ("illegal document revision") error. This is more intuitive and
in line with the corresponding change in the HTTP API. No tests needed
adjustment.
this changes the server startup option `--database.check-30-revisions` from a boolean (true/false)
parameter to a string parameter with the following possible values:
- "fail":
will validate _rev values of 3.0 collections on collection loading and throw an exception when invalid _rev values are found.
in this case collections with invalid _rev values are marked as corrupted and cannot be used in the ArangoDB 3.1 instance.
the fix procedure for such collections is to export the collections from 3.0 database with arangodump and restore them in 3.1 with arangorestore.
collections that do not contain invalid _rev values are marked as ok and will not be re-checked on following loads.
collections that contain invalid _rev values will be re-checked on following loads.
- "true":
will validate _rev values of 3.0 collections on collection loading and print a warning when invalid _rev values are found.
in this case collections with invalid _rev values can be used in the ArangoDB 3.1 instance.
however, subsequent operations on documents with invalid _rev values may silently fail or fail with explicit errors.
the fix procedure for such collections is to export the collections from 3.0 database with arangodump and restore them in 3.1 with arangorestore.
collections that do not contain invalid _rev values are marked as ok and will not be re-checked on following loads.
collections that contain invalid _rev values will be re-checked on following loads.
- "false":
will not validate _rev values on collection loading and not print warnings.
no hint is given when invalid _rev values are found.
subsequent operations on documents with invalid _rev values may silently fail or fail with explicit errors.
this setting does not affect whether collections are re-checked later.
collections will be re-checked on following loads if `--database.check-30-revisions` is later set to either `true` or `fail`.
The change also suppresses warnings that were printed when collections were restored using arangorestore, and the restore
data contained invalid _rev values. Now these warnings are suppressed, and new HLC _rev values are generated for these documents
as before.