Revisit how batch atomic operations are terminated.

[ruebot]

From @birkland on March 17, 2017 20:32

A few questions/confusions related to batch operations surfaced on IRC. The current specification states that a batch operation series can be committed or aborted including an Atomic-Commit or Atomic Abort header along with the last operation.

1. Rolling back a batch operation series by placing the Atomic-Abort header on a POST, PUT, PATCH, DELETE that would otherwise affect the state of a repository resource seems awkward and/or un-intuitive. It is also unclear what HTTP response code a server should respond if an operation fails to perform its stated function, yet is successful in performing its intended function of ending the batch operation.

2. Committing a batch operation currently requires the client to know that a given operation is the last one in a series. There is no way for a client to commit a batch operation as a separate step immediately after all operations in the sequence are finished, unless the client can craft an operation that it knows will not affect the state of any resource otherwise.

3. The spec does not prohibit using safe and idempotent methods to start or end batch operations (OPTIONS, GET, HEAD). Using safe and idempotent operations in this way seems at least questionable with regard to RFC 7231, and its implications on caching is unclear.

Copied from original issue: fcrepo/fcrepo-specification#75

[ruebot]

From @whikloj on March 17, 2017 20:45

While working on the adopters-guide for atomic operations I was wondering (and this may be outside of scope for the specification).

But when you commit or abort an atomic operation, should you receive any atomic headers in the response?

For example.

> curl -i -XPOST -H"Atomic-Start: xxx" -H"Content-type: text/turtle" -d "@resource.ttl" "http://localhost:8080/fcrepo/rest"

HTTP/1.1 201 Created
Date: Fri, 17 Mar 2017 20:07:37 GMT
ETag: W/"fdfa1f25ccab89c5acf7553e364e204657f3a3b5"
Last-Modified: Fri, 17 Mar 2017 20:07:37 GMT
Location: http://localhost:8080/fcrepo/rest/7f/2f/51/24/7f2f5124-fbfe-40cb-9d39-490044c041ca
Atomic-ID: c08010a8-458d-4eb5-b593-d84e0da37744
Content-Type: text/plain
Content-Length: 82
Server: Jetty(9.3.1.v20150714)

http://localhost:8080/fcrepo/rest/7f/2f/51/24/7f2f5124-fbfe-40cb-9d39-490044c041ca

Atomic operation created, now commit it with another POST.

curl -i -XPOST -H"Atomic-ID: c08010a8-458d-4eb5-b593-d84e0da37744" -H"Atomic-Commit: xxx" -H"Content-type: text/turtle" -d "@another_resource.ttl" "http://localhost:8080/fcrepo/rest/7f/2f/51/24/7f2f5124-fbfe-40cb-9d39-490044c041ca"

HTTP/1.1 201 Created
Date: Fri, 17 Mar 2017 20:11:24 GMT
ETag: W/"1505dd0bede6401f08b85e288d546442a93ebf3f"
Last-Modified: Fri, 17 Mar 2017 20:11:24 GMT
Location: http://localhost:8080/fcrepo/rest/7f/2f/51/24/7f2f5124-fbfe-40cb-9d39-490044c041ca/64/4a/92/51/644a9251-74aa-40e2-afb2-5db5ad3d49ec
Content-Type: text/plain
Content-Length: 131
Server: Jetty(9.3.1.v20150714)

http://localhost:8080/fcrepo/rest/7f/2f/51/24/7f2f5124-fbfe-40cb-9d39-490044c041ca/64/4a/92/51/644a9251-74aa-40e2-afb2-5db5ad3d49ec

I didn't add an Atomic-ID to this response, but would you expect to get one to identify that it is still part of, but the last interaction with, that operation?

[ruebot]

From @whikloj on March 17, 2017 20:48

With regards to @birkland's comment above, I agree with #1 and #2.

I have no opinion on #3

[ruebot]

From @awoods on March 17, 2017 23:44

@birkland : from the IRC conversation, your suggestion seems like a logical approach:

whikloj: It does seem weird. My own instinct is that if the little token you get back ought to be a URI, and you commit or roll back the batch op by acting on it

[ruebot]

From @ajs6f on March 18, 2017 12:9

This just mushes together two confusing approaches to make a new approach that is equally confusing, but in new and innovative ways. See @acoburn's new issue.

On Mar 17, 2017, at 7:44 PM, Andrew Woods notifications@github.com wrote:

@birkland : from the IRC conversation, your suggestion seems like a logical approach:

whikloj: It does seem weird. My own instinct is that if the little token you get back ought to be a URI, and you commit or roll back the batch op by acting on it

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or mute the thread.

[ruebot]

From @awoods on March 21, 2017 21:32

Which new issue @ajs6f ?

[ruebot]

From @acoburn on March 21, 2017 21:46

@awoods I believe #76 is what is meant.

[ruebot]

From @acoburn on March 25, 2017 13:5

@birkland could you close this issue and reopen it (possibly with a summary of the discussion here) in the repo with the draft atomic operation spec?

[ruebot]

From @awoods on March 25, 2017 17:49

@birkland : https://github.com/fcrepo/fcrepo-specification-atomic-operations/issues

[peichman-umd]

I would like to revisit the way in which atomic operations are both created and committed/rolled back. While I like the use of the Atomic-ID header to identify requests that should be acted on in the context of the atomic operation, I feel like it would be better to have explicit requests that create, commit, and roll back the operation, instead of having them be implicit based on headers in requests that work on content.

I guess I am envisioning a blend of the existing 4.x transaction behavior and what is currently in this spec. Possible interaction:

Create an atomic batch operation:

POST /rest/fcr:batch
---
201 Created
Location: http://localhost:8080/rest/fcr:batch/0a8d9316-a1c0-4e62-b3e5-c0f0af6bb47d

Create a resource in the context of an atomic operation:

POST /rest/collection
Content-Type: text/turtle
Atomic-ID: http://localhost:8080/rest/fcr:batch/0a8d9316-a1c0-4e62-b3e5-c0f0af6bb47d

<> a pcdm:Object ; ... .
---
201 Created
Location: http://localhost:8080/rest/collection/16/88/df/a2/1688dfa2-b552-4822-9d4d-7aab039d314d
Atomic-ID: http://localhost:8080/rest/fcr:batch/0a8d9316-a1c0-4e62-b3e5-c0f0af6bb47d

Roll back an atomic operation:

DELETE /rest/fcr:batch/0a8d9316-a1c0-4e62-b3e5-c0f0af6bb47d
---
204 No Content

Commit an atomic operation:

PUT /rest/fcr:batch/0a8d9316-a1c0-4e62-b3e5-c0f0af6bb47d
Content-Type: application/json

{"state":"finished"}
---
204 No Content

I am also wondering whether it would be possible to use a Link header with a custom rel instead of minting an entirely new Atomic-ID header.

[dannylamb]

Hey @peichman-umd, thanks for the input. I'm not sure this sidecar spec is going to get much love until the main spec lands, but I think what you're proposing is a good starting point for when we dust this off again.

[peichman-umd]

@dannylamb That makes sense. I just don't want this to fall off the community's radar, since the ability to do these sorts of transactions makes our batch loading logic so much easier 😁