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:49:27 GMT
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 <jens.hueb@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 <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