845745 - CalDAV cached calendars full resync at every startup ! The etag is never stored

Status: RESOLVED WORKSFORME

(Calendar :: Provider: CalDAV, defect)

Description

[Thomas Payen]

User-Agent: Mozilla/5.0 (X11; Linux i686 on x86_64; rv:17.0) Gecko/20130215 Thunderbird/17.0.3 Lightning/1.9

Create a cached calendar on a CalDAV server based on etag synchronisation. Retrieves the calendar events correctly. Then make a change  - create / delete an event - and restart Thunderbird. 

Startup is very slow (because cache problems Bug 412914), in the console in debug mode we can see Lightning do a full resync. At every start, if the calendar's ctag has changed, a full resync is done.

If we open the database cache.sqlite, we see that the table cal_metadata has only one line: calendar-properties. Then it should have a line of metadata per event. So etag are not stored.

Looking at the component calDavCalendar, on addTargetCalendarItem method :
 - for cached calendar the setMetaData is call first
 - then the adoptItem or modifyItem is call
   -> in calStorageCalendar component, adoptItem/modifyItem call flushItem
   -> and flushItem call deleteItemById
   -> and deleteItemById call ... SQL mDeleteMetaData

So it can never work ... Metadata are ALWAYS delete after the insert. In calDavCalendar component, the setMetaData function must be called after the adoptItem/modifyItem functions

Thomas

Comment 1

[Stefan Sitter [:ssitter]]

Could you test Lightning 1.9.1? It is supposed to fix some problems regarding caching. For full list of changes and download location see http://blog.mozilla.org/calendar/2013/02/lightning-1-9-1-release-candidate-available/

Comment 2

[Thomas Payen]

Oh.. it's fixed with Lightning 1.9.1 !

Mea culpa, I saw the Philipp's post but I have not taken time to read it.
So it's OK for me with the 1.9.1, we can close :-)

Comment 3

[Stefan Sitter [:ssitter]]

Thanks for testing. I think this was solved by the patches in Bug 827078.