[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: [OASIS Issue Tracker] Issue Comment Edited: (CMIS-758) Discussion of more powerful batch operations for next version
[ http://tools.oasis-open.org/issues/browse/CMIS-758?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=36387#action_36387 ]
Jay Brown edited comment on CMIS-758 at 1/27/14 4:34 PM:
---------------------------------------------------------
Recap showing current state of feature roll up as promised last meeting ..
Current state of CMIS V.next batch proposal (draft):
---------------------------------------
Updating batch --------------------
---------------------------------------
(covers Create, Update, Delete, Checkin, Checkout, SetContent,
addToFolder, deleteTree, deleteContentStream, (appendContentStream) and removeFromFolder)
A batch request looks like this:
(single) { enum continueOnFail } (mandatory) see [1]
Followed by a list of update batch requests where a update request looks like this:
List {
Id: id of object (mandatory except for create)
folder Id: (for folder related ops like addToFolder and removeFromFolder)
Enum verb: (Create, Update, Delete, Checkin, Checkout, SetContent, AddToFolder, RemoveFromFolder) (Mandatory)
{
inlineContent <cmisra:content> Optional (See [3] for setContent notes)
- If inlineContent is not present then server will check the list of multipart sections for one with a name='' corresponding to this batch items batch number. see [3]
}
Properties <cmis:properties> Optional
}
Batch Response would be a list of the following:
{
Int : sequence number
Id: (resulting object - or of sucessfully deleted object) (e.g. create, checkin)
CMIS Exception and message (optional)
}
Note: If client wants full objects returned for resultset of updating batch they can issue a corresponding FETCH command (see [4] for FETCH details)
For batch requests there will always be N responses for N operations performed. For example if the server encounters 2 different update operations in the batch for the same object it will perform those operations separately and in the same order requested. No collapsing or re-ordering of requests is permitted.
[1] ---------------------------------- ContinueOnFail
ContinueOnFail (three state enum) must be set to one of these values.
-Stop
-Continue (i.e do as much operations in the batch as possible)
-Rollback (i.e. treat each batch as a single unit of work, either all operations completed or none completed).
[2] ---------------- Forward ids support (mandatory):
For every (updating) batch item an implied variable will exist
batch:<batch operation position> (e.g. batch:9 )
that will stand for the id of the resulting object from the operation.
(So there is no additional work to declare them)
This variable can then be used in place of a cmis ID later in the batch.
Note: The variable for a given location will be <not set> for operations in the batch that don't return an id.
Example of a 3 item updating batch that uses this feature:
0 - create document (details...)
1 - create folder (details)
2 - FileDocInFolder (docid=<batch:0> folderid=<id=batch:1>)
Note that batch:2 would be the id of the same folder returned by [1] if it were to be referenced later in the batch.
[3] ------------------- setContentStream
Support for setContentStream in batch POST must support both:
1. Multipart posts so the binary portion can stay in binary form over transport.
2. Base64 encoding of the content inside of the document's metadata (JSON or XML) (like we support today for a createDocument )
Multipart example ------------------
In the case of multipart each binary file section would look something like this:
-- <boundary identifier >
Content-Disposition: form-data; name="batch:xx"; filename=somefile.txt
Content-Type: text/plain
Content-Transfer-Encoding: binary
<binary data here>
-- <next boundary> ...
[4] -------------------- FETCH
FETCH 'id1', 'id2', 'id3',... [PROPERTIES prop1, prop2, ...]
example: FETCH 'id1', 'id2', 'id3', 'idn' PROPERTIES cmis:name, cmis:objectId, cmis:lastModificationDate, cmis:createdBy'
was (Author: jay.brown):
Recap showing current state of feature roll up as promised last meeting ..
Current state of CMIS V.next batch proposal (draft):
---------------------------------------
Updating batch --------------------
---------------------------------------
(covers Create, Update, Delete, Checkin, Checkout, SetContent,
addToFolder, deleteTree, deleteContentStream and removeFromFolder)
A batch request looks like this:
(single) { enum continueOnFail } (mandatory) see [1]
Followed by a list of update batch requests where a update request looks like this:
List {
Id: id of object (mandatory except for create)
folder Id: (for folder related ops like addToFolder and removeFromFolder)
Enum verb: (Create, Update, Delete, Checkin, Checkout, SetContent, AddToFolder, RemoveFromFolder) (Mandatory)
{
inlineContent <cmisra:content> Optional (See [3] for setContent notes)
- If inlineContent is not present then server will check the list of multipart sections for one with a name='' corresponding to this batch items batch number. see [3]
}
Properties <cmis:properties> Optional
}
Batch Response would be a list of the following:
{
Int : sequence number
Id: (resulting object - or of sucessfully deleted object) (e.g. create, checkin)
CMIS Exception and message (optional)
}
Note: If client wants full objects returned for resultset of updating batch they can issue a corresponding FETCH command (see [4] for FETCH details)
For batch requests there will always be N responses for N operations performed. For example if the server encounters 2 different update operations in the batch for the same object it will perform those operations separately and in the same order requested. No collapsing or re-ordering of requests is permitted.
[1] ---------------------------------- ContinueOnFail
ContinueOnFail (three state enum) must be set to one of these values.
-Stop
-Continue (i.e do as much operations in the batch as possible)
-Rollback (i.e. treat each batch as a single unit of work, either all operations completed or none completed).
[2] ---------------- Forward ids support (mandatory):
For every (updating) batch item an implied variable will exist
batch:<batch operation position> (e.g. batch:9 )
that will stand for the id of the resulting object from the operation.
(So there is no additional work to declare them)
This variable can then be used in place of a cmis ID later in the batch.
Note: The variable for a given location will be <not set> for operations in the batch that don't return an id.
Example of a 3 item updating batch that uses this feature:
0 - create document (details...)
1 - create folder (details)
2 - FileDocInFolder (docid=<batch:0> folderid=<id=batch:1>)
Note that batch:2 would be the id of the same folder returned by [1] if it were to be referenced later in the batch.
[3] ------------------- setContentStream
Support for setContentStream in batch POST must support both:
1. Multipart posts so the binary portion can stay in binary form over transport.
2. Base64 encoding of the content inside of the document's metadata (JSON or XML) (like we support today for a createDocument )
Multipart example ------------------
In the case of multipart each binary file section would look something like this:
-- <boundary identifier >
Content-Disposition: form-data; name="batch:xx"; filename=somefile.txt
Content-Type: text/plain
Content-Transfer-Encoding: binary
<binary data here>
-- <next boundary> ...
[4] -------------------- FETCH
FETCH 'id1', 'id2', 'id3',... [PROPERTIES prop1, prop2, ...]
example: FETCH 'id1', 'id2', 'id3', 'idn' PROPERTIES cmis:name, cmis:objectId, cmis:lastModificationDate, cmis:createdBy'
> Discussion of more powerful batch operations for next version
> -------------------------------------------------------------
>
> Key: CMIS-758
> URL: http://tools.oasis-open.org/issues/browse/CMIS-758
> Project: OASIS Content Management Interoperability Services (CMIS) TC
> Issue Type: New Feature
> Components: Domain Model
> Affects Versions: Proposals for 2.0
> Reporter: Jay Brown
>
> Creating this record as a placeholder for discussions on this subject.
> What additional batch features should we support in v.next? (e.g. batch Create, Delete, ...)
> What should they look like? etc.
> Please comment.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]