OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

cmis message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: [OASIS Issue Tracker] Commented: (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=34388#action_34388 ] 

Jay Brown commented on CMIS-758:
--------------------------------

CMIS 1.2 Batch operation strawman proposal 

Two types of complementary batch operations would be added:
 Retrieving & 
 Updating (i.e  read & write)   

---------------------------------------
Retrieving batch --------------------
---------------------------------------
Takes a list of batch retrieval requests where a retrieval request is defined as follows

List {
	sequence number: optional (see discussion at bottom) 
	Id: id of object (mandatory)
	String filter: optional
	Additional Filter info: (all optional)
	Enum includeRelationships: optional
	Boolean includePolicyIds: optional
	String renditionFilter: optional
	Boolean includeACLs: optional
	Boolean includeAllowableActions: optional
}

Discussion Items - We could instead make the 'additional filter info' part of the request (only one copy of these per request) to apply to all the items in the batch.

List of batch retrieval responses where each response in the list is defined as:
{
	Object (looks like a normal getobject response)
	CMIS Exception (with error message) 
}

---------------------------------------
Updating batch --------------------
---------------------------------------
(covers Create, Update, Delete, Checkin, Checkout, SetContent,  
addToFolder and removeFromFolder)

Request looks like this:
{
	boolean rollbackOnFail  (mandatory - some repositories will not support this, in which case must be false) 
	boolean continueOnFail  (mandatory - if rollbackOnFail = false then this determines if server returns after first failure or coninues on to end regardless of errors) 
} 

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) 
	Content <cmisra:content> Optional
	Properties <cmis:properties> Optional
}


Response from an updating batch request 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 retrieving batch by submitting the response from the update (assuming there were no errors) right back to the server as a retrieval request.  

Discussion items:
- For updating 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. 

- If ContinueOnFail == false then there will be <N items in the response.  One response for each of the items up to the first error. 

- If RollbackOnFail == true then there will only be one item in the response. The response for the first error encountered.  All items up to that point will have been rolled back (XA) so no need to return them.   If server supports RollBackOnFail then client must assume entire batch occurs in a transaction.  No partial rollbacks here. 

- Retrieving batch has optional (redundant) sequence number to make it compatible with the response of a Updating batch. 

- Additional repositoryInfo elements: rollbackOnFailure and continueOnFailure
- If Batching will be optional then will also need updatingBatchSupport and retrievingBatchSupport


> 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]