Repository navigation
Bulk API assumes transactional semantics for changing operations #229
Description
Activity
I think that there are different answers:
Retrieve: option C: A retrieve operation always succeeds, it is perfectly normal that a node cannot be found, as we support e.g. dangling references.
Store option E: I would see a store operation as a transaction, it either succeeds completely or fails completely. It will be quite hard for a client to deal with a partially succeeded store operation. And it might semantically be incorrect to store only part of a request. We do need to report back why it failed, so the client can take appropriate action. It might not be a programming error, but also e.g. consurrent update error.
In what way is option A different from option B?
Reacted by Meinte BoersmaI think A = E but with a structured failure response so clients can take appropriate measures.
Ok, I think that we should always send a structured response. The response when failing should become part of the Bulk API specification.
In what way is option A different from option B?
A would fail if any requested node id is unknown. B would succeed and send back "list of node ids not found: ..."
I think A = E but with a structured failure response so clients can take appropriate measures.
A is about any kind of request, E only about modifying requests
Reacted by Jos WarmerPreliminary decision: We cannot come up with a general rule, need to decide individually per command
What should happen if a request to bulk API partially succeeds? Example: We request node ids
x,y, andz, but the repository doesn't knowy.What should happen if a request partially fails? Example: We store nodes
q,r,s,t, andtas child of bothrands.Option A: Whole request fails
If any part of the request is unsuccessful, the whole request fails.
Pro:
Con:
Option B: Request always succeeds, issues are reported back
Pro:
Con:
A client would need to re-model all implicit semantics to understand the effects of partially successful requests
Option C: Non-modifying requests always succeed, omit missing parts
The first example above would return node
xandz.Pro:
Con:
The client needs to compare request and result to figure out that there's no node with id
y.Option D: Modifying requests partially succeed, omit missing parts
The second example above would store node
q, and chose the containment fortthat's mentioned insidet.Pro:
Con:
Option E: Modifying requests completely fails, doesn't change the repository, (reports issues back textually)
If any non-recoverable issue arises during a modifying request, the repository does not apply any changes (or rolls back already applied changes from the same request).
Such an issue is typically a programming error, so the user cannot deal with it. Thus, we don't need a very structured response, but only a hint to the developer.