Re: Mapping DB Bug

["John Stowers" <john stowers gmail com>]

Hmmm that is interesting.

I guess the answer to this is twofold, shall we get a release out the door as is and then convert the dataproviders over to returning datetime in put()? If that is the case, and I think its a good idea, the fix you suggested is fine. 

As long as the basic DB interface isnt changed then im not to worried if there is the odd hack here or there. I intend to move to sqlite or similar in the next major release.

Whats easier for you?

John

On 6/29/07, john carr unrouted co uk <john carr unrouted co uk > wrote:

Morning All

I have found a bug in mappingDB.save_mapping. Consider the following
scenario. Evo contacts and iPod contacts connected together, two way and
not slow sync. Data is added at Evo side. For illustration i'll add two
contacts. After the sync the mapping database would look like this:

Contents of MappingDB: /home/john/Projects/conduit/test/test-data/0241.db
        EvoContactTwoWay-file:///home/john/.evolution/addressbook/local/1182097262 7633 0 laptop
--> IPodContactsTwoWay-
                pas-id-4682594200000040 --> contact1
                pas-id-4682594200000041 --> contact2

No problems there. Now lets modify contact2. In TestSyncPermutation the
"modification" that was triggering this bug seems to be the mtime bug we
already discussed, but i think this bug would still apply after a "real"
change. So modify contact2 and sync. The mapping database now holds:

Contents of MappingDB: /home/john/Projects/conduit/test/test-data/0241.db
        EvoContactTwoWay-file:///home/john/.evolution/addressbook/local/1182097262 7633 0 laptop
--> IPodContactsTwoWay-
                pas-id-4682594200000040 --> contact1
                contact2 --> pas-id-4682594400000042

Needless to say - i was baffled. Debugging shows that the data is passed
to save_mapping correctly so I started to examine that function. It's the
update case thats stinging us.

existing = self._get_mapping(sourceUID, sourceDataLUID, sinkUID)
if existing != None:
    logd("Updating mapping: %s --> %s" % (sourceDataLUID,sinkDataLUID))
    self._db.update(
        existing,
        sourceDataLUID=sourceDataLUID,
        sourceDataMtime=sourceDataMtime,
        sinkDataLUID=sinkDataLUID,
        sinkDataMtime=sinkDataMtime
        )

The problem is that _get_mapping was either modified by myself or based on
one of my patches.. so that it could find *any* mappings for a source,sink
pair. It didn't consider the direction, just that it found the mapping.
However, when updating the record the direction is important. I dont know
how to explain it better than: save_mapping assumes the record is
source->sink but get_mapping can find a record that is either source->sink
or sink->source.

I'm struggling to find a non-invasive fix that is clean. Ultimately we
need to make sure to not have two seperate collections for each pair. (At
the moment there is data for Evo->iPod and seperate data for iPod->Evo).
Possbile a "Conduit SyncPair UID" that is generated when you create a
conduit.. ?

As for now, i've implemented the dirty fix.
http://www.conduit-project.org/changeset/663. Cleanups and alternatives
welcome! TestSyncPermutation is still failing, but i suspect it is a
similar issue and hope to sort it soon.

John

_______________________________________________
Conduit-list mailing list
Conduit-list gnome org
http://mail.gnome.org/mailman/listinfo/conduit-list