You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@chemistry.apache.org by Sascha Homeier <sh...@apollon.de> on 2015/03/06 12:23:17 UTC
[OpenCmis] About behaviour of getContentChanges with null token
parameter
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
Re: [OpenCmis] About behaviour of getContentChanges with null token
parameter
Posted by Sascha Homeier <sh...@apollon.de>.
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.
Cheers
Sascha
> Am 06.03.2015 um 17:17 schrieb Florian Müller <fm...@apache.org>:
>
> 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
>> <sh...@apollon.de>>:
>> 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
>
Re: [OpenCmis] About behaviour of getContentChanges with null token
parameter
Posted by Florian Müller <fm...@apache.org>.
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
> <sh...@apollon.de>>:
>
> 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
Re: [OpenCmis] About behaviour of getContentChanges with null token
parameter
Posted by Sascha Homeier <sh...@apollon.de>.
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 <sh...@apollon.de>>:
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