creating multiple Documents in a single cmis:Folder in a single method call

[Mark Streit <mc...@gmail.com>]

Hello

I have a question about the POTENTIAL ability to "create" Documents (in a 1
to many manner) in one call instead of individual calls to
Folder.createDocument() when sending more than one document to the *same *
Folder.

Today of course with CMIS 1.0, we can do this: (this excerpt is simply
taken from the page at
http://chemistry.apache.org/java/examples/example-create-update.html )

      Folder parent = ....; // (get the folder object from the repository)

      String name = "myNewDocument.txt";

      // properties
      // (minimal set: name and object type id)
      Map<String, Object> properties = new HashMap<String, Object>();
      properties.put(PropertyIds.OBJECT_TYPE_ID, "cmis:document");
      properties.put(PropertyIds.NAME, name);

      // content
      byte[] content = "Hello World!".getBytes();
      InputStream stream = new ByteArrayInputStream(content);
      ContentStream contentStream = new ContentStreamImpl(name,
BigInteger.valueOf(content.length), "text/plain", stream);

      // create a major version
      Document newDoc = parent.createDocument(properties,
contentStream, VersioningState.MAJOR);


I know that CMIS 1.1 is currently under review ... but did not pick up
any evidence of being able to support something like the notion of the
following:


Say for instance I have


      Folder folder0 = .....; // (I get the folder object from the repository)

      String name1 = "myNewDocument1.txt";
      String name2 = "myNewDocument2.txt";

      // properties
      // (minimal set: name and object type id)

      // set the map for the 1st document
      Map<String, Object> properties1 = new HashMap<String, Object>();
      properties1.put(PropertyIds.OBJECT_TYPE_ID, "cmis:document");
      properties1.put(PropertyIds.NAME, name1);

      // set the map for the 2nd document
      Map<String, Object> properties2 = new HashMap<String, Object>();
      properties2.put(PropertyIds.OBJECT_TYPE_ID, "cmis:document");
      properties2.put(PropertyIds.NAME, name2);

      // content streams for each - byte[] arrays first
      byte[] content1 = "This is test document 1".getBytes();
      InputStream stream1 = new ByteArrayInputStream(content1);
      byte[] content2 = "This is test document 2".getBytes();
      InputStream stream2 = new ByteArrayInputStream(content2);

      // content stream creation


      ContentStream contentStream1 = new ContentStreamImpl(name1,
BigInteger.valueOf(content1.length), "text/plain", stream1);
      ContentStream contentStream2 = new ContentStreamImpl(name2,
BigInteger.valueOf(content2.length), "text/plain", stream2);



      // create a "document list"


      DocumentList docList = new ArrayList<DocumentItem>();



      DocumentItem docItem = new DocumentItem(properties1,
contentStream1, VersioningState.MAJOR);
      docList.add(docItem);

      docItem = new DocumentItem(properties2, contentStream2,
VersioningState.MAJOR);
      docList.add(docItem);

      List<Document> docs = folder0.createDocuments(docList);


I do realize that one would have to be careful in that a client application
that might try to send a LARGE number of these in a single call would pose
a problem. I was thinking more in the line of say 5-10 documents at one
time at most as a practical matter. What I am nor sure is how best one
controls that - perhaps some type of check in the CLIENT API so that a
large payload would not get "on the wire" for such a call.

Just a thought I'd throw out there.


Thanks

Mark

Re: creating multiple Documents in a single cmis:Folder in a single method call

[Florian Müller <fm...@apache.org>]

Hi Mark,

CMIS 1.0 does not specify any bulk operations. CMIS 1.1 adds an 
operation to update the properties of multiple objects with one call. 
OpenCMIS implements the standard but not any additional functionalities 
to be compatible with as many clients and servers as possible.

Bulk operations and transaction support have been discussed in the TC. 
Some simple bulk operations like the one you described would be 
technically possible with the existing CMIS data structures. (Although 
we would have to violate the AtomPub spec here and there.) We postponed 
that topic to CMIS 2.0 without a clear idea how to do it.

Funnily enough, a private discussion started a few days ago between some 
of the CMIS key players. There is an idea how to make bulk operations 
and transactions possible and how to implement that *beside* the 
OpenCMIS server framework. I can't promise anything, but maybe there 
will be a sandbox project soon that provides such functionalities.


Btw. session.createDocument(...) makes fewer calls than 
folder.createDocument(...) because the latter makes an additional call 
to fetch the newly created document.


- Florian


> Hello
>
> I have a question about the POTENTIAL ability to "create" Documents (in a 1
> to many manner) in one call instead of individual calls to
> Folder.createDocument() when sending more than one document to the *same *
> Folder.
>
> Today of course with CMIS 1.0, we can do this: (this excerpt is simply
> taken from the page at
> http://chemistry.apache.org/java/examples/example-create-update.html )
>
>        Folder parent = ....; // (get the folder object from the repository)
>
>        String name = "myNewDocument.txt";
>
>        // properties
>        // (minimal set: name and object type id)
>        Map<String, Object>  properties = new HashMap<String, Object>();
>        properties.put(PropertyIds.OBJECT_TYPE_ID, "cmis:document");
>        properties.put(PropertyIds.NAME, name);
>
>        // content
>        byte[] content = "Hello World!".getBytes();
>        InputStream stream = new ByteArrayInputStream(content);
>        ContentStream contentStream = new ContentStreamImpl(name,
> BigInteger.valueOf(content.length), "text/plain", stream);
>
>        // create a major version
>        Document newDoc = parent.createDocument(properties,
> contentStream, VersioningState.MAJOR);
>
>
> I know that CMIS 1.1 is currently under review ... but did not pick up
> any evidence of being able to support something like the notion of the
> following:
>
>
> Say for instance I have
>
>
>        Folder folder0 = .....; // (I get the folder object from the repository)
>
>        String name1 = "myNewDocument1.txt";
>        String name2 = "myNewDocument2.txt";
>
>        // properties
>        // (minimal set: name and object type id)
>
>        // set the map for the 1st document
>        Map<String, Object>  properties1 = new HashMap<String, Object>();
>        properties1.put(PropertyIds.OBJECT_TYPE_ID, "cmis:document");
>        properties1.put(PropertyIds.NAME, name1);
>
>        // set the map for the 2nd document
>        Map<String, Object>  properties2 = new HashMap<String, Object>();
>        properties2.put(PropertyIds.OBJECT_TYPE_ID, "cmis:document");
>        properties2.put(PropertyIds.NAME, name2);
>
>        // content streams for each - byte[] arrays first
>        byte[] content1 = "This is test document 1".getBytes();
>        InputStream stream1 = new ByteArrayInputStream(content1);
>        byte[] content2 = "This is test document 2".getBytes();
>        InputStream stream2 = new ByteArrayInputStream(content2);
>
>        // content stream creation
>
>
>        ContentStream contentStream1 = new ContentStreamImpl(name1,
> BigInteger.valueOf(content1.length), "text/plain", stream1);
>        ContentStream contentStream2 = new ContentStreamImpl(name2,
> BigInteger.valueOf(content2.length), "text/plain", stream2);
>
>
>
>        // create a "document list"
>
>
>        DocumentList docList = new ArrayList<DocumentItem>();
>
>
>
>        DocumentItem docItem = new DocumentItem(properties1,
> contentStream1, VersioningState.MAJOR);
>        docList.add(docItem);
>
>        docItem = new DocumentItem(properties2, contentStream2,
> VersioningState.MAJOR);
>        docList.add(docItem);
>
>        List<Document>  docs = folder0.createDocuments(docList);
>
>
> I do realize that one would have to be careful in that a client application
> that might try to send a LARGE number of these in a single call would pose
> a problem. I was thinking more in the line of say 5-10 documents at one
> time at most as a practical matter. What I am nor sure is how best one
> controls that - perhaps some type of check in the CLIENT API so that a
> large payload would not get "on the wire" for such a call.
>
> Just a thought I'd throw out there.
>
>
> Thanks
>
> Mark
>