You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@chemistry.apache.org by Tim Webster <ti...@gmail.com> on 2013/04/11 13:44:11 UTC
Returned ObjectId on check in (WS vs. AtomPub)
Hi All,
I've noticed that the ObjectId returned from a check-in operation is
different depending on the binding type used.
If atompub is used, the check in operation will always return the the 'new'
objectId (i.e. the object ID of the new version that is being created by
the check in).
If webservices is used, the check in operation will always return the
objectId of the Document that is being checked in.
I've tested both scenarios using the following inputs as the document to
check in:
- v1.0 of the document
- latest major version of the document
- PWC of the document
I initially thought this might be a bug in the CMIS repository
implementation I'm using (IBM FileNet P8), as the Chemistry client code
seems to just return what is returned from the server. However the same
behavior exists in OpenCMIS InMemory Server as well.
It would be odd if this was a bug AND showing up in two different
implementations.
I couldn't see anything in the spec regarding this, so am now wondering if
I've missed something or if in fact this is a problem with the Chemistry
client somehow.
Any thoughts?
Thanks,
Tim
Re: Returned ObjectId on check in (WS vs. AtomPub)
Posted by Tim Webster <ti...@gmail.com>.
There were properties on the PWC that the user saw as incorrect,
specifically 'creation date' and 'created by'. The reason for this is that
these properties reflect the PWC, not the 'first version' of the document,
which is what they want to see. Our initial workaround was to not return
the PWC after the check-out, but rather the original document they are
checking in.
What was then happening was we'd check in the 'first version' and we were
getting the latest version ID back from the repository, which we would then
display to the user. Thinking about it more, I guess this was done without
realizing we were checking in a non-PWC, because it all worked the way we
expected. Until, that is, we switched to WS binding, when all of a sudden
the latest ID wasn't being returned and on check in the 'old' document was
being displayed instead of the new one.
In the end I implemented a 'proper' fix. We return the PWC on checkout,
but with the creation date and created by properties from the FIRST (or
earliest) version of the document. The whole reason for this requirement
is that our old DMS system (FileNet Content Services) behaves in this
manner, and we wanted to keep this consistent. The user wants to see when
and by whom the FIRST version of the document was added, not the LAST.
Tim
On Fri, Apr 12, 2013 at 11:38 AM, Florent Guillaume <fg...@nuxeo.com> wrote:
> On Fri, Apr 12, 2013 at 12:30 PM, Tim Webster <ti...@gmail.com>
> wrote:
> > Picture a query result set within our client application, similar to what
> > you'd see in the CMIS Workbench. In it, the user doesn't want to 'see'
> the
> > PWC if a document is checked out, they only want to see the LMV. So on
> > checkout, we don't send the PWC to the client. To do a check in, we need
> to
> > then fetch the PWC (if we're using WS).
>
> Sorry if I seem obtuse, but if the client doesn't see the PWC then why
> would he want to do a checkin? The checkin is basically saying "I'm
> done with the PWC", right?
>
> (Just trying to get to the bottom of this because it's always
> important to me to discover and understand new use cases in document
> managements systems, especially around versioning.)
>
> Florent
>
> --
> Florent Guillaume, Director of R&D, Nuxeo
> Open Source, Java EE based, Enterprise Content Management (ECM)
> http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87
>
--
Check out my wine blog: http://timswineblog.blogspot.com/
Re: Returned ObjectId on check in (WS vs. AtomPub)
Posted by Florent Guillaume <fg...@nuxeo.com>.
On Fri, Apr 12, 2013 at 12:30 PM, Tim Webster <ti...@gmail.com> wrote:
> Picture a query result set within our client application, similar to what
> you'd see in the CMIS Workbench. In it, the user doesn't want to 'see' the
> PWC if a document is checked out, they only want to see the LMV. So on
> checkout, we don't send the PWC to the client. To do a check in, we need to
> then fetch the PWC (if we're using WS).
Sorry if I seem obtuse, but if the client doesn't see the PWC then why
would he want to do a checkin? The checkin is basically saying "I'm
done with the PWC", right?
(Just trying to get to the bottom of this because it's always
important to me to discover and understand new use cases in document
managements systems, especially around versioning.)
Florent
--
Florent Guillaume, Director of R&D, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87
Re: Returned ObjectId on check in (WS vs. AtomPub)
Posted by Tim Webster <ti...@gmail.com>.
Hi Florent,
Picture a query result set within our client application, similar to what
you'd see in the CMIS Workbench. In it, the user doesn't want to 'see' the
PWC if a document is checked out, they only want to see the LMV. So on
checkout, we don't send the PWC to the client. To do a check in, we need to
then fetch the PWC (if we're using WS).
Don't get me wrong, this issue isn't preventing us from delivering a
solution. There are several easy workarounds, including returning the PWC
as you say (but then we'd have to hide certain details, etc), returning the
PWC ID with the PMV, etc. There are levels of translation between CMIS and
proprietary document objects that need to occur which complicates it and I
don't really want to get into that.
Basically I just wanted to highlight the differences in behavior between WS
and AtomPub bindings on the server implementations. They shouldn't be
different. How this is reconciled I'm not too bothered about, as long as
it's consistent :-)
Tim
On Fri, Apr 12, 2013 at 11:16 AM, Florent Guillaume <fg...@nuxeo.com> wrote:
> Hi,
>
> On Fri, Apr 12, 2013 at 10:42 AM, Tim Webster <ti...@gmail.com>
> wrote:
> > This allows client
> > application to avoid having to do another fetch from the repository to
> get
> > the PWC.
>
> I don't understand your use case at all. A checkin is an action
> *about* the PWC, that basically requires rights on it, so in what
> circumstances would a client not have access to its ID anyway?
>
> > One of my current business scenarios requires me to check in the latest
> > major version (LMV) of a document (because we don't make the PWC
> available
> > to the client).
>
> Huh? Could you detail that? If the client doesn't have access to the
> PWC then what is the PWC good for?
>
> Regards,
> Florent
>
> --
> Florent Guillaume, Director of R&D, Nuxeo
> Open Source, Java EE based, Enterprise Content Management (ECM)
> http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87
>
--
Check out my wine blog: http://timswineblog.blogspot.com/
Re: Returned ObjectId on check in (WS vs. AtomPub)
Posted by Florent Guillaume <fg...@nuxeo.com>.
Hi,
On Fri, Apr 12, 2013 at 10:42 AM, Tim Webster <ti...@gmail.com> wrote:
> This allows client
> application to avoid having to do another fetch from the repository to get
> the PWC.
I don't understand your use case at all. A checkin is an action
*about* the PWC, that basically requires rights on it, so in what
circumstances would a client not have access to its ID anyway?
> One of my current business scenarios requires me to check in the latest
> major version (LMV) of a document (because we don't make the PWC available
> to the client).
Huh? Could you detail that? If the client doesn't have access to the
PWC then what is the PWC good for?
Regards,
Florent
--
Florent Guillaume, Director of R&D, Nuxeo
Open Source, Java EE based, Enterprise Content Management (ECM)
http://www.nuxeo.com http://www.nuxeo.org +33 1 40 33 79 87
Re: Returned ObjectId on check in (WS vs. AtomPub)
Posted by Tim Webster <ti...@gmail.com>.
Hi Jay,
Yes I agree that it would be best if the WS and AtomPub bindings behaved in
the same manner with regards to the ObjectId returned, favoring the AtomPub
behavior.
And I agree that it is convenient to be able to accept any version of the
object for check in, even if it's not the PWC. This allows client
application to avoid having to do another fetch from the repository to get
the PWC.
One of my current business scenarios requires me to check in the latest
major version (LMV) of a document (because we don't make the PWC available
to the client). Because of the WS binding issue, I've used a workaround
where I fetch the PWC of the document, and then check that in instead of
the LMV because I know that will return the latest version ID of the
document (which we DO make available to the client). So to reiterate, this
ability to check in any version of the document and then obtain the latest
version ID is very convenient, so yeah I would be against taking that out
(even if it's not in the spec).
Tim
On Thu, Apr 11, 2013 at 6:50 PM, Jay Brown <ja...@us.ibm.com> wrote:
> Right.
>
> We made the decision in the case where a client asks for a checkin (but
> passes the object rather than the PWC) we would confirm everything was
> right (doc was checked out, etc) and if it was we would go ahead and do the
> checkin. Since that is clearly what the user intended. (as a convenience)
>
> This is not a behavior strictly described in the spec, though I don't
> believe it is forbidden either.
>
> So it sounds to me like we (IBM FileNet) should tweak our WS binding of
> the P8 implementation so that it conforms to the behavior of the REST side.
>
>
> Would you agree? The other thing we could do to normalize this would be
> to stop accepting anything but the PWC for checkin ops. But I don't think
> that would make our implementation better for clients.
>
>
> (Note: I have not personally verified this WS scenario yet. )
>
>
> Jay Brown
> Senior Engineer, ECM Development
> IBM Software Group
> jay.brown@us.ibm.com
>
>
> [image: Inactive hide details for Tim Webster ---04/11/2013 10:18:17
> AM---Hi, So what is happening is that P8 makes the assumption that]Tim
> Webster ---04/11/2013 10:18:17 AM---Hi, So what is happening is that P8
> makes the assumption that you are checking
>
>
>
> From:
>
>
> Tim Webster <ti...@gmail.com>
>
> To:
>
>
> dev@chemistry.apache.org,
>
> Date:
>
>
> 04/11/2013 10:18 AM
>
> Subject:
>
>
> Re: Returned ObjectId on check in (WS vs. AtomPub)
> ------------------------------
>
>
>
> Hi,
>
> So what is happening is that P8 makes the assumption that you are checking
> in the PWC. I agree that checking in the PWC should normally should be the
> case.
>
> However, checkins seem to work even if the document you are checking in is
> not the PWC (and this behavior is convenient), and it is in this scenario
> that we get different behavior, as outlined in my last message.
>
>
> Tim
>
>
>
> On Thu, Apr 11, 2013 at 5:21 PM, Jay Brown <ja...@us.ibm.com> wrote:
>
> > In the case of FileNet P8 these two scenarios are often the same.
> >
> > For p8 when you checkin a document the PWC becomes (or gets promoted) to
> > the new version.
> > This means that the ID of the PWC and the ID of the new version are
> > identical. (Not sure if inMemory also does this)
> >
> > So the p8 specific rules (because of this implementation detail) is that
> > whatever you checkin (both bindings) you will get back an id that is the
> > same as the (former) PWC. It is just not a PWC anymore, but now is the
> > latest version.
> >
> >
> >
> > Jay Brown
> > Senior Engineer, ECM Development
> > IBM Software Group
> > jay.brown@us.ibm.com
> >
> > [image: Inactive hide details for Tim Webster ---04/11/2013 04:46:11
> > AM---Hi All, I've noticed that the ObjectId returned from a check-]Tim
> > Webster ---04/11/2013 04:46:11 AM---Hi All, I've noticed that the
> ObjectId
> > returned from a check-in operation is
> >
> >
> >
> > From:
> >
> >
> > Tim Webster <ti...@gmail.com>
> >
> > To:
> >
> >
> > dev@chemistry.apache.org,
> >
> > Date:
> >
> >
> > 04/11/2013 04:46 AM
> >
> > Subject:
>
> >
> >
> > Returned ObjectId on check in (WS vs. AtomPub)
> > ------------------------------
>
> >
> >
> >
> > Hi All,
> >
> > I've noticed that the ObjectId returned from a check-in operation is
> > different depending on the binding type used.
> >
> > If atompub is used, the check in operation will always return the the
> 'new'
> > objectId (i.e. the object ID of the new version that is being created by
> > the check in).
> >
> > If webservices is used, the check in operation will always return the
> > objectId of the Document that is being checked in.
> >
> > I've tested both scenarios using the following inputs as the document to
> > check in:
> >
> > - v1.0 of the document
> > - latest major version of the document
> > - PWC of the document
> >
> > I initially thought this might be a bug in the CMIS repository
> > implementation I'm using (IBM FileNet P8), as the Chemistry client code
> > seems to just return what is returned from the server. However the same
> > behavior exists in OpenCMIS InMemory Server as well.
> >
> > It would be odd if this was a bug AND showing up in two different
> > implementations.
> >
> > I couldn't see anything in the spec regarding this, so am now wondering
> if
> > I've missed something or if in fact this is a problem with the Chemistry
> > client somehow.
> >
> > Any thoughts?
> >
> > Thanks,
> >
> > Tim
> >
> >
> >
>
>
> --
> Check out my wine blog:
> http://timswineblog.blogspot.com/
>
>
>
--
Check out my wine blog: http://timswineblog.blogspot.com/
Re: Returned ObjectId on check in (WS vs. AtomPub)
Posted by Tim Webster <ti...@gmail.com>.
Hi Jens,
You don't really need me to supply any code snippets, all you need to do is
check in a non-PWC version of a checked out document, and observe that the
atompub and WS bindings return different values. The WS binding returns
the ID of the document you checked in, and the atompub binding returns the
PWC ID (aka the newest document version ID).
Tim
On Thu, Apr 11, 2013 at 9:29 PM, Jens Hübel <je...@gmail.com> wrote:
> The InMemory repository behaves similar. You have to provide the id of the
> PWC in a check-in call and the id is never changed. The InMemory repository
> always returns what it gets. The different behavior between the two
> bindings is a bit surprising to me. Can you share some code to reproduce
> this behavior?
>
>
> On Thu, Apr 11, 2013 at 7:50 PM, Jay Brown <ja...@us.ibm.com> wrote:
>
> > Right.
> >
> > We made the decision in the case where a client asks for a checkin (but
> > passes the object rather than the PWC) we would confirm everything was
> > right (doc was checked out, etc) and if it was we would go ahead and do
> the
> > checkin. Since that is clearly what the user intended. (as a
> convenience)
> >
> > This is not a behavior strictly described in the spec, though I don't
> > believe it is forbidden either.
> >
> > So it sounds to me like we (IBM FileNet) should tweak our WS binding of
> > the P8 implementation so that it conforms to the behavior of the REST
> side.
> >
> >
> > Would you agree? The other thing we could do to normalize this would be
> > to stop accepting anything but the PWC for checkin ops. But I don't
> think
> > that would make our implementation better for clients.
> >
> >
> > (Note: I have not personally verified this WS scenario yet. )
> >
> >
> > Jay Brown
> > Senior Engineer, ECM Development
> > IBM Software Group
> > jay.brown@us.ibm.com
> >
> >
> > [image: Inactive hide details for Tim Webster ---04/11/2013 10:18:17
> > AM---Hi, So what is happening is that P8 makes the assumption that]Tim
> > Webster ---04/11/2013 10:18:17 AM---Hi, So what is happening is that P8
> > makes the assumption that you are checking
> >
> >
> >
> > From:
> >
> >
> > Tim Webster <ti...@gmail.com>
> >
> > To:
> >
> >
> > dev@chemistry.apache.org,
> >
> > Date:
> >
> >
> > 04/11/2013 10:18 AM
> >
> > Subject:
> >
> >
> > Re: Returned ObjectId on check in (WS vs. AtomPub)
> > ------------------------------
> >
> >
> >
> > Hi,
> >
> > So what is happening is that P8 makes the assumption that you are
> checking
> > in the PWC. I agree that checking in the PWC should normally should be
> the
> > case.
> >
> > However, checkins seem to work even if the document you are checking in
> is
> > not the PWC (and this behavior is convenient), and it is in this scenario
> > that we get different behavior, as outlined in my last message.
> >
> >
> > Tim
> >
> >
> >
> > On Thu, Apr 11, 2013 at 5:21 PM, Jay Brown <ja...@us.ibm.com> wrote:
> >
> > > In the case of FileNet P8 these two scenarios are often the same.
> > >
> > > For p8 when you checkin a document the PWC becomes (or gets promoted)
> to
> > > the new version.
> > > This means that the ID of the PWC and the ID of the new version are
> > > identical. (Not sure if inMemory also does this)
> > >
> > > So the p8 specific rules (because of this implementation detail) is
> that
> > > whatever you checkin (both bindings) you will get back an id that is
> the
> > > same as the (former) PWC. It is just not a PWC anymore, but now is the
> > > latest version.
> > >
> > >
> > >
> > > Jay Brown
> > > Senior Engineer, ECM Development
> > > IBM Software Group
> > > jay.brown@us.ibm.com
> > >
> > > [image: Inactive hide details for Tim Webster ---04/11/2013 04:46:11
> > > AM---Hi All, I've noticed that the ObjectId returned from a check-]Tim
> > > Webster ---04/11/2013 04:46:11 AM---Hi All, I've noticed that the
> > ObjectId
> > > returned from a check-in operation is
> > >
> > >
> > >
> > > From:
> > >
> > >
> > > Tim Webster <ti...@gmail.com>
> > >
> > > To:
> > >
> > >
> > > dev@chemistry.apache.org,
> > >
> > > Date:
> > >
> > >
> > > 04/11/2013 04:46 AM
> > >
> > > Subject:
> > >
> > >
> > > Returned ObjectId on check in (WS vs. AtomPub)
> > > ------------------------------
> > >
> > >
> > >
> > > Hi All,
> > >
> > > I've noticed that the ObjectId returned from a check-in operation is
> > > different depending on the binding type used.
> > >
> > > If atompub is used, the check in operation will always return the the
> > 'new'
> > > objectId (i.e. the object ID of the new version that is being created
> by
> > > the check in).
> > >
> > > If webservices is used, the check in operation will always return the
> > > objectId of the Document that is being checked in.
> > >
> > > I've tested both scenarios using the following inputs as the document
> to
> > > check in:
> > >
> > > - v1.0 of the document
> > > - latest major version of the document
> > > - PWC of the document
> > >
> > > I initially thought this might be a bug in the CMIS repository
> > > implementation I'm using (IBM FileNet P8), as the Chemistry client code
> > > seems to just return what is returned from the server. However the
> same
> > > behavior exists in OpenCMIS InMemory Server as well.
> > >
> > > It would be odd if this was a bug AND showing up in two different
> > > implementations.
> > >
> > > I couldn't see anything in the spec regarding this, so am now wondering
> > if
> > > I've missed something or if in fact this is a problem with the
> Chemistry
> > > client somehow.
> > >
> > > Any thoughts?
> > >
> > > Thanks,
> > >
> > > Tim
> > >
> > >
> > >
> >
> >
> > --
> > Check out my wine blog: http://timswineblog.blogspot.com/
> >
> >
> >
>
--
Check out my wine blog: http://timswineblog.blogspot.com/
Re: Returned ObjectId on check in (WS vs. AtomPub)
Posted by Jens Hübel <je...@gmail.com>.
The InMemory repository behaves similar. You have to provide the id of the
PWC in a check-in call and the id is never changed. The InMemory repository
always returns what it gets. The different behavior between the two
bindings is a bit surprising to me. Can you share some code to reproduce
this behavior?
On Thu, Apr 11, 2013 at 7:50 PM, Jay Brown <ja...@us.ibm.com> wrote:
> Right.
>
> We made the decision in the case where a client asks for a checkin (but
> passes the object rather than the PWC) we would confirm everything was
> right (doc was checked out, etc) and if it was we would go ahead and do the
> checkin. Since that is clearly what the user intended. (as a convenience)
>
> This is not a behavior strictly described in the spec, though I don't
> believe it is forbidden either.
>
> So it sounds to me like we (IBM FileNet) should tweak our WS binding of
> the P8 implementation so that it conforms to the behavior of the REST side.
>
>
> Would you agree? The other thing we could do to normalize this would be
> to stop accepting anything but the PWC for checkin ops. But I don't think
> that would make our implementation better for clients.
>
>
> (Note: I have not personally verified this WS scenario yet. )
>
>
> Jay Brown
> Senior Engineer, ECM Development
> IBM Software Group
> jay.brown@us.ibm.com
>
>
> [image: Inactive hide details for Tim Webster ---04/11/2013 10:18:17
> AM---Hi, So what is happening is that P8 makes the assumption that]Tim
> Webster ---04/11/2013 10:18:17 AM---Hi, So what is happening is that P8
> makes the assumption that you are checking
>
>
>
> From:
>
>
> Tim Webster <ti...@gmail.com>
>
> To:
>
>
> dev@chemistry.apache.org,
>
> Date:
>
>
> 04/11/2013 10:18 AM
>
> Subject:
>
>
> Re: Returned ObjectId on check in (WS vs. AtomPub)
> ------------------------------
>
>
>
> Hi,
>
> So what is happening is that P8 makes the assumption that you are checking
> in the PWC. I agree that checking in the PWC should normally should be the
> case.
>
> However, checkins seem to work even if the document you are checking in is
> not the PWC (and this behavior is convenient), and it is in this scenario
> that we get different behavior, as outlined in my last message.
>
>
> Tim
>
>
>
> On Thu, Apr 11, 2013 at 5:21 PM, Jay Brown <ja...@us.ibm.com> wrote:
>
> > In the case of FileNet P8 these two scenarios are often the same.
> >
> > For p8 when you checkin a document the PWC becomes (or gets promoted) to
> > the new version.
> > This means that the ID of the PWC and the ID of the new version are
> > identical. (Not sure if inMemory also does this)
> >
> > So the p8 specific rules (because of this implementation detail) is that
> > whatever you checkin (both bindings) you will get back an id that is the
> > same as the (former) PWC. It is just not a PWC anymore, but now is the
> > latest version.
> >
> >
> >
> > Jay Brown
> > Senior Engineer, ECM Development
> > IBM Software Group
> > jay.brown@us.ibm.com
> >
> > [image: Inactive hide details for Tim Webster ---04/11/2013 04:46:11
> > AM---Hi All, I've noticed that the ObjectId returned from a check-]Tim
> > Webster ---04/11/2013 04:46:11 AM---Hi All, I've noticed that the
> ObjectId
> > returned from a check-in operation is
> >
> >
> >
> > From:
> >
> >
> > Tim Webster <ti...@gmail.com>
> >
> > To:
> >
> >
> > dev@chemistry.apache.org,
> >
> > Date:
> >
> >
> > 04/11/2013 04:46 AM
> >
> > Subject:
> >
> >
> > Returned ObjectId on check in (WS vs. AtomPub)
> > ------------------------------
> >
> >
> >
> > Hi All,
> >
> > I've noticed that the ObjectId returned from a check-in operation is
> > different depending on the binding type used.
> >
> > If atompub is used, the check in operation will always return the the
> 'new'
> > objectId (i.e. the object ID of the new version that is being created by
> > the check in).
> >
> > If webservices is used, the check in operation will always return the
> > objectId of the Document that is being checked in.
> >
> > I've tested both scenarios using the following inputs as the document to
> > check in:
> >
> > - v1.0 of the document
> > - latest major version of the document
> > - PWC of the document
> >
> > I initially thought this might be a bug in the CMIS repository
> > implementation I'm using (IBM FileNet P8), as the Chemistry client code
> > seems to just return what is returned from the server. However the same
> > behavior exists in OpenCMIS InMemory Server as well.
> >
> > It would be odd if this was a bug AND showing up in two different
> > implementations.
> >
> > I couldn't see anything in the spec regarding this, so am now wondering
> if
> > I've missed something or if in fact this is a problem with the Chemistry
> > client somehow.
> >
> > Any thoughts?
> >
> > Thanks,
> >
> > Tim
> >
> >
> >
>
>
> --
> Check out my wine blog: http://timswineblog.blogspot.com/
>
>
>
Re: Returned ObjectId on check in (WS vs. AtomPub)
Posted by Jay Brown <ja...@us.ibm.com>.
Right.
We made the decision in the case where a client asks for a checkin (but
passes the object rather than the PWC) we would confirm everything was
right (doc was checked out, etc) and if it was we would go ahead and do the
checkin. Since that is clearly what the user intended. (as a convenience)
This is not a behavior strictly described in the spec, though I don't
believe it is forbidden either.
So it sounds to me like we (IBM FileNet) should tweak our WS binding of the
P8 implementation so that it conforms to the behavior of the REST side.
Would you agree? The other thing we could do to normalize this would be to
stop accepting anything but the PWC for checkin ops. But I don't think
that would make our implementation better for clients.
(Note: I have not personally verified this WS scenario yet. )
Jay Brown
Senior Engineer, ECM Development
IBM Software Group
jay.brown@us.ibm.com
From: Tim Webster <ti...@gmail.com>
To: dev@chemistry.apache.org,
Date: 04/11/2013 10:18 AM
Subject: Re: Returned ObjectId on check in (WS vs. AtomPub)
Hi,
So what is happening is that P8 makes the assumption that you are checking
in the PWC. I agree that checking in the PWC should normally should be the
case.
However, checkins seem to work even if the document you are checking in is
not the PWC (and this behavior is convenient), and it is in this scenario
that we get different behavior, as outlined in my last message.
Tim
On Thu, Apr 11, 2013 at 5:21 PM, Jay Brown <ja...@us.ibm.com> wrote:
> In the case of FileNet P8 these two scenarios are often the same.
>
> For p8 when you checkin a document the PWC becomes (or gets promoted) to
> the new version.
> This means that the ID of the PWC and the ID of the new version are
> identical. (Not sure if inMemory also does this)
>
> So the p8 specific rules (because of this implementation detail) is that
> whatever you checkin (both bindings) you will get back an id that is the
> same as the (former) PWC. It is just not a PWC anymore, but now is the
> latest version.
>
>
>
> Jay Brown
> Senior Engineer, ECM Development
> IBM Software Group
> jay.brown@us.ibm.com
>
> [image: Inactive hide details for Tim Webster ---04/11/2013 04:46:11
> AM---Hi All, I've noticed that the ObjectId returned from a check-]Tim
> Webster ---04/11/2013 04:46:11 AM---Hi All, I've noticed that the
ObjectId
> returned from a check-in operation is
>
>
>
> From:
>
>
> Tim Webster <ti...@gmail.com>
>
> To:
>
>
> dev@chemistry.apache.org,
>
> Date:
>
>
> 04/11/2013 04:46 AM
>
> Subject:
>
>
> Returned ObjectId on check in (WS vs. AtomPub)
> ------------------------------
>
>
>
> Hi All,
>
> I've noticed that the ObjectId returned from a check-in operation is
> different depending on the binding type used.
>
> If atompub is used, the check in operation will always return the the
'new'
> objectId (i.e. the object ID of the new version that is being created by
> the check in).
>
> If webservices is used, the check in operation will always return the
> objectId of the Document that is being checked in.
>
> I've tested both scenarios using the following inputs as the document to
> check in:
>
> - v1.0 of the document
> - latest major version of the document
> - PWC of the document
>
> I initially thought this might be a bug in the CMIS repository
> implementation I'm using (IBM FileNet P8), as the Chemistry client code
> seems to just return what is returned from the server. However the same
> behavior exists in OpenCMIS InMemory Server as well.
>
> It would be odd if this was a bug AND showing up in two different
> implementations.
>
> I couldn't see anything in the spec regarding this, so am now wondering
if
> I've missed something or if in fact this is a problem with the Chemistry
> client somehow.
>
> Any thoughts?
>
> Thanks,
>
> Tim
>
>
>
--
Check out my wine blog: http://timswineblog.blogspot.com/
Re: Returned ObjectId on check in (WS vs. AtomPub)
Posted by Tim Webster <ti...@gmail.com>.
Hi,
So what is happening is that P8 makes the assumption that you are checking
in the PWC. I agree that checking in the PWC should normally should be the
case.
However, checkins seem to work even if the document you are checking in is
not the PWC (and this behavior is convenient), and it is in this scenario
that we get different behavior, as outlined in my last message.
Tim
On Thu, Apr 11, 2013 at 5:21 PM, Jay Brown <ja...@us.ibm.com> wrote:
> In the case of FileNet P8 these two scenarios are often the same.
>
> For p8 when you checkin a document the PWC becomes (or gets promoted) to
> the new version.
> This means that the ID of the PWC and the ID of the new version are
> identical. (Not sure if inMemory also does this)
>
> So the p8 specific rules (because of this implementation detail) is that
> whatever you checkin (both bindings) you will get back an id that is the
> same as the (former) PWC. It is just not a PWC anymore, but now is the
> latest version.
>
>
>
> Jay Brown
> Senior Engineer, ECM Development
> IBM Software Group
> jay.brown@us.ibm.com
>
> [image: Inactive hide details for Tim Webster ---04/11/2013 04:46:11
> AM---Hi All, I've noticed that the ObjectId returned from a check-]Tim
> Webster ---04/11/2013 04:46:11 AM---Hi All, I've noticed that the ObjectId
> returned from a check-in operation is
>
>
>
> From:
>
>
> Tim Webster <ti...@gmail.com>
>
> To:
>
>
> dev@chemistry.apache.org,
>
> Date:
>
>
> 04/11/2013 04:46 AM
>
> Subject:
>
>
> Returned ObjectId on check in (WS vs. AtomPub)
> ------------------------------
>
>
>
> Hi All,
>
> I've noticed that the ObjectId returned from a check-in operation is
> different depending on the binding type used.
>
> If atompub is used, the check in operation will always return the the 'new'
> objectId (i.e. the object ID of the new version that is being created by
> the check in).
>
> If webservices is used, the check in operation will always return the
> objectId of the Document that is being checked in.
>
> I've tested both scenarios using the following inputs as the document to
> check in:
>
> - v1.0 of the document
> - latest major version of the document
> - PWC of the document
>
> I initially thought this might be a bug in the CMIS repository
> implementation I'm using (IBM FileNet P8), as the Chemistry client code
> seems to just return what is returned from the server. However the same
> behavior exists in OpenCMIS InMemory Server as well.
>
> It would be odd if this was a bug AND showing up in two different
> implementations.
>
> I couldn't see anything in the spec regarding this, so am now wondering if
> I've missed something or if in fact this is a problem with the Chemistry
> client somehow.
>
> Any thoughts?
>
> Thanks,
>
> Tim
>
>
>
--
Check out my wine blog: http://timswineblog.blogspot.com/
Re: Returned ObjectId on check in (WS vs. AtomPub)
Posted by Jay Brown <ja...@us.ibm.com>.
In the case of FileNet P8 these two scenarios are often the same.
For p8 when you checkin a document the PWC becomes (or gets promoted) to
the new version.
This means that the ID of the PWC and the ID of the new version are
identical. (Not sure if inMemory also does this)
So the p8 specific rules (because of this implementation detail) is that
whatever you checkin (both bindings) you will get back an id that is the
same as the (former) PWC. It is just not a PWC anymore, but now is the
latest version.
Jay Brown
Senior Engineer, ECM Development
IBM Software Group
jay.brown@us.ibm.com
From: Tim Webster <ti...@gmail.com>
To: dev@chemistry.apache.org,
Date: 04/11/2013 04:46 AM
Subject: Returned ObjectId on check in (WS vs. AtomPub)
Hi All,
I've noticed that the ObjectId returned from a check-in operation is
different depending on the binding type used.
If atompub is used, the check in operation will always return the the 'new'
objectId (i.e. the object ID of the new version that is being created by
the check in).
If webservices is used, the check in operation will always return the
objectId of the Document that is being checked in.
I've tested both scenarios using the following inputs as the document to
check in:
- v1.0 of the document
- latest major version of the document
- PWC of the document
I initially thought this might be a bug in the CMIS repository
implementation I'm using (IBM FileNet P8), as the Chemistry client code
seems to just return what is returned from the server. However the same
behavior exists in OpenCMIS InMemory Server as well.
It would be odd if this was a bug AND showing up in two different
implementations.
I couldn't see anything in the spec regarding this, so am now wondering if
I've missed something or if in fact this is a problem with the Chemistry
client somehow.
Any thoughts?
Thanks,
Tim