Hi Patrick,
On Oct 26, 2009, at 13:50 , Patrick Ohly wrote:
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.
Probably, yes.
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():
That changed a long time ago (long before libsynthesis release).
Apparently the comments in sync_dbapi.h and also the docs in the
SDK_manual were not updated. I remember updating the SQL docs for
these changes and documenting the need to include the entrytype (what
is called ident in DBApi) into the primary key.
/*! 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?
Yes.
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?
It could, depending on the circumstances. Normal map entries have
ident==1, but when the peer has a limited size for GUIDs
(<maxguidsize>) which is smaller than actual localIDs of the server,
the server needs to use temporary GUIDs and stores these with ident==2.
So if the peer was also SyncEvolution, it is unlikely tempguids could
cause problems, because the maxguidsize should be large enough to
avoid the need for temporary GUIDs. Standard cell phone clients
however are likely to need temporary GUIDs.
Best Regards,
Lukas Zeller ([email protected])
-
Synthesis AG, SyncML Solutions & Sustainable Software Concepts
[email protected], http://www.synthesis.ch
_______________________________________________
os-libsynthesis mailing list
[email protected]
http://lists.synthesis.ch/mailman/listinfo/os-libsynthesis
