On Fri, 2009-10-23 at 18:48 +0100, Lukas Zeller wrote: > On Oct 23, 2009, at 14:52 , Patrick Ohly wrote: > > > I'm not exactly sure how I got my server data into such a state, but I > > ended up with entries in my local to remote ID map which only had a > > local ID. > > This is a perfectly normal intermediate state - these are "unconfirmed > add" entries waiting for a <Map> command from the client.
I thought so. I just don't know exactly what I did to create those. I must have killed the client at just the right time. > Note however that you cannot use the localID alone as primary key to > the maps, as there might be valid cases when there are multiple > entries for the same localid (but with different entrytype/ident). That's not what the sync_dbapi.h says. It explicitly mentions "localID" alone as the key. For example, UpdateMapItem(): /*! Map table handling: Update a map item of this context * * @param <aContext> The datastore context * @param <mID> MapID ( with \<localID>,\<remoteID>, <flags> and \<ident> ). * If there is already a MapID element with localID, it * will be update, else created. So the documentation is wrong here? > Do you have the full HTML log of the session that created this call? Yes, at home. I'll check once I get back. > > My implementation of that call faithfully checks whether the item > > already exists and if so, refuses to update it, as specified in > > sync_dbapi.h. > > Should be ok - as long as you use the (localID,ident) pair as identity > and not localID alone. Right now it only uses localID. Could that be the explanation for the problem? -- Best Regards, Patrick Ohly The content of this message is my personal opinion only and although I am an employee of Intel, the statements I make here in no way represent Intel's position on the issue, nor am I authorized to speak on behalf of Intel on this matter. _______________________________________________ os-libsynthesis mailing list [email protected] http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
