chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Tim Webster <tim.webs...@gmail.com>
Subject Re: Returned ObjectId on check in (WS vs. AtomPub)
Date Fri, 12 Apr 2013 08:42:04 GMT
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 <jay.brown@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 <tim.webster@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 <jay.brown@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 <tim.webster@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/

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message