If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

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



Provider: CalDAV
5 years ago
5 years ago


(Reporter: Thomas Payen, Unassigned)


Lightning 1.9




5 years ago
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


Comment 1

5 years ago
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

5 years ago
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 :-)
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME

Comment 3

5 years ago
Thanks for testing. I think this was solved by the patches in Bug 827078.
Depends on: 827078
Target Milestone: --- → 1.9.1
You need to log in before you can comment on or make changes to this bug.