- Notifications
You must be signed in to change notification settings - Fork 57
Refactor batch API docs #173
Conversation
|
… into feature/batch-api-refactor
… into feature/batch-api-refactor
| ||
 | ||
| ||
From the outside this process is fully transparent: >ou talk to any _Coordinator_ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From the outside this process is fully transparent: >ou talk to any _Coordinator_ | |
From the outside this process is fully transparent: you talk to any _Coordinator_ |
| ||
From the outside this process is fully transparent: >ou talk to any _Coordinator_ | ||
and whenever you read or write data | ||
it will automatically figure out where the data is stored (read) or to |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it will automatically figure out where the data is stored (read) or to | |
it will automatically figure out where the data is (to be) stored. |
From the outside this process is fully transparent: >ou talk to any _Coordinator_ | ||
and whenever you read or write data | ||
it will automatically figure out where the data is stored (read) or to | ||
be stored (write). The information about the _shards_ is shared across the |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
be stored (write). The information about the _shards_ is shared across the | |
The information about the _shards_ is shared across the _Coordinators_ using the _Agency_. |
Note however that if you change the shard keys from their default `["_key"]`, then finding | ||
a document in the collection by its primary key involves a request to | ||
every single shard. However this can be mitigate: All CRUD APIs and AQL | ||
support taking the shard key values as a lookup hint. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How do you hint the shard key in practice?
3.6/administration-cluster.md Outdated
support taking the shard keys as a lookup hint. | ||
every single shard. However this can be mitigated: All CRUD APIs and AQL | ||
support taking the shard keys as a lookup hint. Just send them as part | ||
of the update / replace or removal operation. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I assume the respective attributes need to be present in the request for the CRUD APIs?
In case of AQL, does it work with all syntax variants?
UPDATE "docKey" WITH { myShardAttribute: "foo", ... }
UPDATE { _key: "docKey", myShardAttribute: "foo", ...}
UPDATE { _key: "docKey", myShardAttribute: "foo" } WITH { ... }
???UPSERT { _key: "docKey", myShardAttribute: "foo" }
... ?UPSERT { _key: "docKey" } INSERT { myShardAttribute: "foo", ... } UPDATE { myShardAttribute: "foo", ... }
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes feel free to add it to the docs yourself. This always used to work reliably except for remove operations, new in 3.6 is only that it now does work everywhere
arangodb/arangodb#10015
http://jenkins01.arangodb.biz:8080/view/Documentation/job/arangodb-ANY-examples/345/