[Tickets #12770] Sync "loop" of Kolab categories <-> Horde tags sync

[noreply at bugs.horde.org]

DO NOT REPLY TO THIS MESSAGE. THIS EMAIL ADDRESS IS NOT MONITORED.

Ticket URL: http://bugs.horde.org/ticket/12770
------------------------------------------------------------------------------
  Ticket             | 12770
  Created By         | Thomas Jarosch <thomas.jarosch at intra2net.com>
  Summary            | Sync "loop" of Kolab categories <-> Horde tags sync
  Queue              | Kronolith
  Version            | Git master
  Type               | Bug
  State              | Unconfirmed
  Priority           | 1. Low
  Milestone          |
  Patch              |
  Owners             |
------------------------------------------------------------------------------


Thomas Jarosch <thomas.jarosch at intra2net.com> (2013-10-16 14:38) wrote:

Hi,

consider this scenario with a new, empty calendar:

1. User inserts the first event. The event is tagged with "foobar".
    This tag is inserted into the tagging backend.
2. User creates another event with a foreign Kolab client.
    This event is tagged "Foobar" (noticed the capital 'F')
3. kronolith syncs in the foreign event. The Kolab sync tells
    the tag backend to store the tag(s) for the new event object,
    it does a case insensitive search for an existing tag label.
    -> it picks the existing row id of "foobar".


The next time Event::synchronizeTags() runs, it notices
the tags given by the Kolab driver for the second event
differ from the tag backend ("Foobar" != "foobar")
     -> A sync is triggered.

I have a productive calendar with about 2.000 events.
The sync "loop" produces 3.6000+ INSERT / UPDATE statements
on every click. Yikes.

Please consider the attached patch, which makes the
tag comparison case insensitive.

If the patch gets approved, we need to fix
the tag sync of the other applications, too.

Another option would be to make the tagger backend
case sensitive, but that would lead to duplicate entries
because of lower / uppercase spelling. Not really an option.

Without the patch, browsing around in the calendar
takes about seven seconds for each click on a box with a SSD.
With the patch it's about one second.

Note: I removed the strcoll() based sorting, it is of no use,
array_diff() does not care about the order of elements.

Cheers,
Thomas