Re: Mapping DB Bug

[john carr unrouted co uk]

Yes, get a release out showing off the the full evo support + box.net then
fix the underlying mapping db. I'm voting that we do sqlite support in
0.3.3?

John

> 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
>>
>