On Do, 2010-12-09 at 13:18 +0000, Lukas Zeller wrote:
> > So you are saying that entries with ident == 2 are never meant to be
> > removed from the mapping?
>
> Not exactly that - what I'm saying is that these are (or should)
> always be removed all together. So either the list is still growing,
> or all of its items should go away at the same time, which cleans up
> the ID space.
I might have found it.
Scenario:
- SERVER is the ID on the server, CLIENT on the client
- server has a mapping from SERVER to #35 (ident 2) and to CLIENT (ident 1)
- item is deleted on server
- two-way sync
What I now see in the log is this:
fTempGUIDMap: restore mapping from #35 to SERVER
Item LocalID='SERVER', RemoteID='CLIENT', operation=delete
SyncOp=delete: LocalID=SERVER RemoteID=CLIENT
fTempGUIDMap: translated realLocalID='SERVER' to tempLocalID='#63'
The fTempGUIDMap is a map tempLocalID->ID. It now contains #65->SERVER and
#35->SERVER.
But the map in the DB AP is a map from (ID, ident) -> ([remote ID], flags).
It cannot hold both #65->SERVER and #35->SERVER. So what I see next is the
saving of these two entries:
ModifyMap called: aEntryType=tempidmap, aLocalID='SERVER, aRemoteid='#35',
aMapflags=0x0, aDelete=0
found entry by entrytype/localID='SERVER' - remoteid='#35', mapflags=0x0,
changed=0, deleted=1, added=0, markforresume=0, savedmark=0
ModifyMap called: aEntryType=tempidmap, aLocalID='SERVER, aRemoteid='#63',
aMapflags=0x0, aDelete=0
found entry by entrytype/localID='SERVER' - remoteid='#35', mapflags=0x0,
changed=0, deleted=0, added=0, markforresume=0, savedmark=0
apiSaveAdminData: entryType=normal, localid='SERVER', remoteID='CLIENT',
mapflags=0x8, changed=0, deleted=0, added=0, markforresume=1, savedmark=0
UpdateMapItem 'SERVER' + 1 = 'CLIENT' + 9, res=0
apiSaveAdminData: entryType=tempidmap, localid='SERVER', remoteID='#63',
mapflags=0x0, changed=1, deleted=0, added=0, markforresume=0, savedmark=0
UpdateMapItem 'SERVER' + 2 = '#63' + 0, res=0
The last UpdateMapItem overwrites the entry for #35, because it uses the
same ID + ident.
The next sync then populates fTempGUIDMap with entry #63, but has no #35
and thus the size() + 1 assumption no longer holds.
I remember that I was confused about the map item DB calls. Originally I
implemented that as (ID) -> (ident, [remote ID], flags). But after we
discussed it, I changed that to (ID, ident) -> ([remote ID], flags),
which IMHO is what the API description says:
/*! 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>
and \<ident>,
* it will be updated, else created.
*
* @return error code, if this MapID can't be updated (e.g. not yet existing).
*
* USED ONLY WITH \<plugin_datastoredadmin>
*/
_ENTRY_ TSyError UpdateMapItem( CContext aContext, cMapID mID );
So, what is the solution to this problem? Do I still misunderstand
something or is there a genuine problem? ;-/
FWIW, there was one DeleteMapItem for item SERVER in the sessions above,
but it was for ident 1 (after deleting it).
--
Best Regards
Patrick Ohly
Senior Software Engineer
Intel GmbH
Open Source Technology Center
Pützstr. 5 Phone: +49-228-2493652
53129 Bonn
Germany
_______________________________________________
os-libsynthesis mailing list
[email protected]
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
