chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Sascha Homeier <>
Subject Re: [OpenCmis] About behaviour of getContentChanges with null token parameter
Date Fri, 06 Mar 2015 17:03:15 GMT
Hi Florian,

thx for quick response.
This makes much more sense now.

According to 2):
I simply forgot to set the value of the Holder with the latest token on server side.
Now all my unit tests shine green ;)
Thx for the hint.


> Am 06.03.2015 um 17:17 schrieb Florian Müller <>:
> Hi Sascha,
> The maxItems parameter defines how many entries should be returned (at most). If the
client does not specify the maxItems parameter, the server can decide.
> I agree the spec wording could be better. It should be:
> "If not specified, then the repository MUST return the first change event recorded in
the change log [as the first result in the output]."
> A client can receive all change events from the beginning of time with one call (if the
repository supports this) by providing no change log token.
> Re 2)
> The latestChangeLogToken is not the one that is passed in. It's a holder variable that
is updated in the getContentChanges() method of the respective binding implementation. Whatever
the server returned as "changeLogToken" is used here.
> - Florian
>> 2)
>> I am a bit irritated about client library behaviour when getting
>> latestChangeLogToken from ChangeEvent:
>> It seems to always return the token which is passed as argument of
>> method ‚getContentChanges‘.
>> A look inside SessionImpl class confirmed that the token parameter is
>> passed through to create ChangeEventsImpl.
>> Shouldn’t the latestChangeLogToken be the one at the end of the
>> changeEvents List retrieved from server?
>> Due to spec the token which is passed as parameter should be the FIRST
>> result in the output. So the first change event in list should
>> correspond to this token.
>> And the latestChangeLogToken should be „The change log token
>> corresponding to the LAST change event in changeEvents.“
>> Do I miss sth. here?
>> (Don’t want to immediately create a bug ticket because I think its
>> more probably that I misunderstood sth.)
>> tia
>> Cheers
>> Sascha
>> Am 06.03.2015 um 12:23 schrieb Sascha Homeier
>> <<>>:
>> Hello together,
>> I am currently implementing the ChangeLog functionality on server side
>> and have a question concerning the spec conformant behavior of
>> Discovery Service „getContentChanges“:
>> Due to get the very first change event the CMIS spec 1.1 says I need
>> to pass a null changeLogToken parameter:
>> *   String changeLogToken: If specified, then the repository MUST
>> return the change event corresponding to the value of the specified
>> change log token as the first result in the output.
>> If not specified, then the repository MUST return the first change event
>> recorded in the change log.
>> So did I understand it correctly that at server side I should only
>> pass ONE change event which must be the very first event (either from
>> beginning if ChangeLog capability provides complete log or otherwise
>> from the point in time when changes were recorded)?
>> So if I am on the right track I think to get ALL change events from
>> beginning of the ChangeLog on client-side I should first ask for the
>> first change event with token parameter null and then ask for the
>> events since that token.
>> So client-code should look like that imho:
>> // get very first change event
>> ItemIterable<ChangeEvent> contentChanges =
>> cmisSession.getContentChanges(null, includeProperties);
>> ChangeEvent veryFirstChangeEvent = contentChanges.iterator().next();
>> // get change log token of very first event and ask for the first page
>> of change events on going-forward basis
>> CmisObject veryFirstCmisObject =
>> cmisSession.getObject(veryFirstChangeEvent.getObjectId());
>> ChangeEvents allContentChangesFirstPage =
>> cmisSession.getContentChanges(veryFirstCmisObject.getChangeToken(),
>> includeProperties, maxItems);
>> It would be nice if someone could just confirm if this is the intended
>> and spec compliant repository behaviour.
>> I am not fully sure if the server reply for a null token parameter
>> should really only be ONE change event (the very first) or ALL change
>> events beginning with the very first.
>> thx in advance.
>> Cheers
>> Sascha

View raw message