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 <[email protected]> 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 > [email protected] > > > [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 <[email protected]> > > To: > > > [email protected], > > 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 <[email protected]> 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 > > [email protected] > > > > [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 <[email protected]> > > > > To: > > > > > > [email protected], > > > > 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/ > > >
