chemistry-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jens Hübel <jens.h...@gmail.com>
Subject Re: Returned ObjectId on check in (WS vs. AtomPub)
Date Thu, 11 Apr 2013 20:29:46 GMT
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/
>
>
>

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