Re: Re: questions regardingZOGi,WAS:[OGo-Users]custom fields and synchronizing ogo

> > You shouldn't need to bump the version number,  the version number needs
> > to be equal to the version on the server.
> I added 1 to the object_version I found in the database, and that did not 
> worked, I had the assumption, that I need to specify the next version, when 
> I do an update, and not the version that I want to update. I ran into an 
> python exception, when I tried to update with this:
> xmlrpclib.Fault: <Fault 0: 'HTTP 500: Client object is out of date'>
> specifying the flag, "fixes" the problem for me.

Ah, so it is working perfectly. :)  Unless you specify the ignoreVersion
flag you should get a "HTTP 500: Client object is out of date" unless
the version number of the presented entity is the *same* as the version
number of the server object.  This ensures that you aren't updating the
data of an object that has changed since you looked at it [via a
getObject or whatever].  For bulk loads it doesn't much matter, hence
the "ignoreVersion" flag, but I strongly encourage actual applications
to handle object versions otherwise you get a last-writer-wins scenario
and the concomitant potential data loss.

The getObjectVersionsById
<http://code.google.com/p/zogi/wiki/getObjectVersionsById> method exists
to allow an application a bulk method of simply scanning it's cache for
out-of-date objects.  Then you can update what you can and provide the
user with a list of conflicting objects and allow them to decide how to
proceed.

-- 
OpenGroupware.org XML-RPC
[email protected]
http://mail.opengroupware.org/mailman/listinfo/xmlrpc