Hi Mike,
I hope I've some answers for you.
Re a) Holds are stored as a multi-value property. CMIS only allows
retrieving and updating multi-value properties as a whole. There is no
support for partial retrieval or partial update.
But if a client doesn't modify the list of holds, it shouldn't send it
to the server. Hence, there is no need for the server to retrieve the
list of holds all the time.
Do you except a frequent change of holds on an object? In the use cases
I know, holds are not updated very often.
Re b) That shouldn't happen if your server implements change tokens
correctly. Change tokens are supposed to prevent lost updates.
- Florian
Hi all,
In the current CMIS 1.1 spec, hold is supported by secondary type.
Specifically, the user can add/remove ids from cmis:hold.rm_holdIds to
add/remove holds. There are two major issues here.
a) The user need to firstly retrieve out the whole hold list before
the
user can add/remove hold. The list might be a big one depends on
business needs. In CMIS server side implementation, we need to
firstly
retrieve out this list from content server and compare it to the
list in
the update request. So that we get to know which one should be
added/removed. Even though there is no change in this list, we still
need to do the retrieve and compare practice in each checkin. This
will
not perform well.
b) May result in inconsistences in consequent updates. For example,
user
A is trying to add a hold, so it pass the original list plus the one
that it wants to add hold. Now user B wants to add another hold. If
user
B's original list had been retrieved out before user A completed the
update, then user A's update will be overwritten by user B's update,
unintentionally.
So, I wonder whether there is a better way to add/remove holds without
going through the retrieve and compare logic in an update(checkin).
Thanks
in advance!
Best Regards,
Mike Li(李永亮)
IBM Content Manager RM Development
Tel:(86-10)82453403 Fax:(86-10)58851920 Tie-line: 905-3403
liyo...@cn.ibm.com
