1
0
Fork 0
arangodb/arangod
jsteemann 5f65a9ed4f allow more control over handling of pre-3.1 _rev values
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.
2016-11-04 23:17:01 +01:00
..
Actions switch to boost asio 2016-10-14 10:12:17 +00:00
Agency Recapsulating MUTEX in key value Store 2016-11-04 11:42:08 +01:00
Aql Waiting for leader election in AgencyComm::sendWithFailover 2016-11-03 14:24:45 +01:00
Cluster allow more control over handling of pre-3.1 _rev values 2016-11-04 23:17:01 +01:00
FulltextIndex Squashed commit of the following: 2016-10-24 10:18:30 +02:00
GeneralServer remove unused test code 2016-10-31 13:08:13 +01:00
GeoIndex Squashed commit of the following: 2016-10-24 10:18:30 +02:00
Indexes do not prefer primary indexes in that many situations 2016-11-03 17:40:17 +01:00
InternalRestHandler switch to boost asio 2016-10-14 10:12:17 +00:00
Replication Squashed commit of the following: 2016-10-24 10:18:30 +02:00
Rest
RestHandler allow more control over handling of pre-3.1 _rev values 2016-11-04 23:17:01 +01:00
RestServer allow more control over handling of pre-3.1 _rev values 2016-11-04 23:17:01 +01:00
Scheduler fix Visual Studio complaints 2016-10-31 09:59:18 +01:00
Statistics Squashed commit of the following: 2016-10-27 09:26:18 +02:00
StorageEngine allow more control over handling of pre-3.1 _rev values 2016-11-04 23:17:01 +01:00
Utils allow more control over handling of pre-3.1 _rev values 2016-11-04 23:17:01 +01:00
V8Server allow more control over handling of pre-3.1 _rev values 2016-11-04 23:17:01 +01:00
VocBase allow more control over handling of pre-3.1 _rev values 2016-11-04 23:17:01 +01:00
Wal Squashed commit of the following: 2016-10-24 10:18:30 +02:00
CMakeLists.txt remove non-unused PathHandler 2016-10-31 12:15:07 +01:00