This allows changing the internals of TRI_vector_t structs in order to make the struct smaller.
On 64 bits, the size of TRI_vector_t is reduced from 48 bytes to 28 bytes.
TRI_json_t does benefit from this, as its biggest component is a TRI_vector_t.
This change extends the HTTP REST API for bulk imports as follows:
When documents are imported and the `_key` attribute is specified for them, the import can be
used for inserting and updating/replacing documents. Previously, the import could be used for
inserting new documents only, and re-inserting a document with an existing would have failed
with a *unique key constraint violated* error.
The above behavior is still the default. However, the API now allows controlling the behavior
in case of a unique key constraint error via the optional URL parameter `onDuplicate`.
This parameter can have one of the following values:
- `error`: when a unique key constraint error occurs, do not import or update the document but
report an error. This is the default.
- `update`: when a unique key constraint error occurs, try to (partially) update the existing
document with the data specified in the import. This may still fail if the document would
violate secondary unique indexes. Only the attributes present in the import data will be
updated and other attributes already present will be preserved. The number of updated documents
will be reported in the `updated` attribute of the HTTP API result.
- `replace`: when a unique key constraint error occurs, try to fully replace the existing
document with the data specified in the import. This may still fail if the document would
violate secondary unique indexes. The number of replaced documents will be reported in the
`updated` attribute of the HTTP API result.
- `ignore`: when a unique key constraint error occurs, ignore this error. There will be no
insert, update or replace for the particular document. Ignored documents will be reported
separately in the `ignored` attribute of the HTTP API result.
The result of the HTTP import API will now contain the attributes `ignored` and `updated`, which
contain the number of ignored and updated documents respectively. These attributes will contain a
value of zero unless the `onDuplicate` URL parameter is set to either `update` or `replace`
(in this case the `updated` attribute may contain non-zero values) or `ignore` (in this case the
`ignored` attribute may contain a non-zero value).
Locking is now done in an extra round after the query is fully
instanciated in the cluster. All participating shards are locked
in alphabetical order of their shard ID (local collection name).
For this to work there is a new action in the RestAqlHandler plus a
mechanism to prevent the usual locking from happening: Each thread has a
thread local static class variable of
triagens::arango::Transaction::_makeNolockHeaders
which is of type std::unordered_set<std::string>*.
Whenever this is not equal to nullptr and a local collection name is
stored in there, no locking or unlocking takes place. This information
is forwarded by the X-Arango-Nolock HTTP header, whenever an HTTP
request is sent via ClusterComm to a shard.
- create edge operation with 202 result is returned when waitForSync was
set to false
- add missing If-None-Match header parameter description to read head
operation
- add information about _key attribute in result for replace, update and
delete operations
In particular:
- Notice if collections mentioned in _from and _to fields of edges
do not exist.
- In cluster case make the coordinator report errors from the
DBservers better.
- Fail more quickly if arangorestore does not go well.