After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 652177 - libecal: Allow a quick check for "data changed".
libecal: Allow a quick check for "data changed".
Status: RESOLVED FIXED
Product: evolution-data-server
Classification: Platform
Component: Calendar
3.4.x (obsolete)
Other Linux
: Normal normal
: ---
Assigned To: evolution-calendar-maintainers
Evolution QA team
meego
Depends on:
Blocks:
 
 
Reported: 2011-06-09 10:07 UTC by Murray Cumming
Modified: 2013-09-14 16:55 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Patch to add e_cal_get_revision() [targetting meego-eds branch] (28.22 KB, patch)
2011-08-04 21:49 UTC, Tristan Van Berkom
none Details | Review
Patch to add e_cal_get_revision() [targetting master branch] (22.50 KB, patch)
2011-08-05 01:43 UTC, Tristan Van Berkom
none Details | Review
Patch to add e_cal_get_revision() [targetting master branch, take 2] (22.10 KB, patch)
2011-10-13 17:06 UTC, Tristan Van Berkom
needs-work Details | Review
Patch to add revision backend property to ECal (7.44 KB, patch)
2011-11-22 09:54 UTC, Tristan Van Berkom
needs-work Details | Review
Patch to add revision backend property to ECal [take 2] (9.82 KB, patch)
2011-11-23 10:22 UTC, Tristan Van Berkom
committed Details | Review

Description Murray Cumming 2011-06-09 10:07:57 UTC
The libecal API should offer a way to discover if any data whatsoever has
changed. This would, for instance, help SyncEvolution to avoid unnecessary
detailed checking. This could just check the modification dates of local
storage files, such as the .ics file. This would be much quicker than
listing items for the whole database and comparing their revisions strings, as
is currently necessary.

This would require small API additions, to check that the opaque revision
strings are unchanged, such as

gchar* e_cal_get_revision(ECal *ecal)
gboolean e_cal_check_revision(ECal ecal, const gchar revision)

We hope to provide a patch for this, so please let us know if it's likely to be
acceptable.
Comment 1 Tristan Van Berkom 2011-08-04 21:49:14 UTC
Created attachment 193280 [details] [review]
Patch to add e_cal_get_revision() [targetting meego-eds branch]

This patch adds e_cal_get_revision() much like e_book_get_revision()
from bug 652175.

Note this patch is targeting the 'meego-eds' branch and not master
(patch for master still needs to be cooked).

In the local calendar backend in this case, the actual file modification
time is used and the file is saved to disk if needed before generating
the revision timestamp.

On 'openismus-work' as usual you will find an accompanying test case:
   calendar/tests/ecal/test-ecal-get-revision.c

Commit on 'openismus-work' branch is:

commit a780f922ddb4c60b90fab141953d2d3894c42524
Author: Tristan Van Berkom <tristan.van.berkom@gmail.com>
Date:   Thu Aug 4 14:18:46 2011 -0400

    Added e_cal_get_revision().
    
    Adds e_cal_get_revision() async/sync api to access an
    opaque revision string which will be NULL for a backend that
    does not implement it. Adds all the needed gdbus machinery and
    implements a revision in the file backend.
    
    This is implemented by checking the calendar file timestamp and
    maintaining a modification counter to ensure there are no races
    when multiple revisions happen in the same second. When the backend
    is asked for it's revision and it's currently dirty... the calendar
    file is forcefully saved to ensure a correct revision string.
    
    Bug: https://bugzilla.gnome.org/show_bug.cgi?id=652177
Comment 2 Tristan Van Berkom 2011-08-05 01:43:36 UTC
Created attachment 193289 [details] [review]
Patch to add e_cal_get_revision() [targetting master branch]

And this is the ported version of the patch to master branch.

The test case on 'openismus-work-master' branch is:
  tests/libecal/client/test-client-get-revision.c

and the commit for this patch on 'openismus-work-master' is:

commit ff86182250463f0af07e63b812e3ef1395db62bc
Author: Tristan Van Berkom <tristan.van.berkom@gmail.com>
Date:   Thu Aug 4 21:30:35 2011 -0400
Comment 3 Tristan Van Berkom 2011-08-05 01:48:05 UTC
Note to reviewer.

There is one thing I'm not entirely sure about, the code is short and
comment inline so I'll just post it here:

static void
e_cal_backend_file_get_revision (ECalBackend *backend, EDataCal *cal, guint32 opid, GCancellable *cancellable)
{
	ECalBackendFile *cbfile = E_CAL_BACKEND_FILE (backend);
	gchar *revision;

	/* Sync the file right now because we need a timestamp to
	 * make a revision
	 */
	if (cbfile->priv->is_dirty) {
		if (cbfile->priv->dirty_idle_id) {
			g_source_remove (cbfile->priv->dirty_idle_id);
			cbfile->priv->dirty_idle_id = 0;
		}
		save_file_when_idle (cbfile);

		/* Do we need to reset 'refresh_skip' here ?? */
		/* priv->refresh_skip = 0; */
	}

	/* Notify with the revision */
	revision = get_revision_string (cbfile);
        ...
}

The above bit which forces the file to be saved 
right away if dirty is copied from 'refresh_thread_func()'
where it sets 'priv->refresh_skip' to 0, it's unclear to
me if that should be done also in this case.
Comment 4 Tristan Van Berkom 2011-10-13 17:06:42 UTC
Created attachment 198957 [details] [review]
Patch to add e_cal_get_revision() [targetting master branch, take 2]

Refreshing patches for a huge rebase of 'openismus-work-master' branch off of
the current master branch.

Attaching new patch for master.

New related commits on 'openismus-work-master' branch are:

commit 54c1452c0ff35de3c6990978527176a60c672b1c
Author: Tristan Van Berkom <tristan.van.berkom@gmail.com>
Date:   Thu Aug 4 21:32:09 2011 -0400

    Added test case for e_cal_get_revision().....

commit 874827860088477d3add9548aedeaffbd292d2ff
Author: Tristan Van Berkom <tristan.van.berkom@gmail.com>
Date:   Thu Aug 4 21:30:35 2011 -0400

    Added e_cal_get_revision()....
Comment 5 Milan Crha 2011-10-31 10:50:26 UTC
Similar comment like in bug #652175, please make it a backend property, without API changes.

For the implementation itself, I do not see the revision counter being saved anywhere, and the 'save' function is not the best one for the counter increment either, because the file is saved on open too. It means the revision string will differ right after opening - it's because check_dup_uid() call.

You can usually use a cache for this, but the file backend doesn't have it, it has everything in an iCal string. Try if you are able to add an X property on a toplevel VCALENDAR property, the one for revision. I suppose a icalcomponent_add_property() will work, for an X property "X-EVOLUTION-REVISION" (get inspired by icomp_x_prop_set(), icomp_x_prop_get() in http://git.gnome.org/browse/evolution-data-server/tree/calendar/backends/caldav/e-cal-backend-caldav.c )

Another issue in later versions of eds can be that the calendar backends would be freed when no longer needed (they are kept alive till the end of a factory process, where addressbook factory frees its backends immediately when no need for them is kept). I believe this difference will be avoided one day, in one or the other way. Who knows which. Just it can make difference in your current patch too.
Comment 6 Tristan Van Berkom 2011-11-22 09:54:53 UTC
Created attachment 201909 [details] [review]
Patch to add revision backend property to ECal

Ok here's the good patch.

Removed all the api overhead and implemented as a property (this time
re-added the common property definition to e-client.h).

This one uses g_get_current_time & g_time_val_to_isoSOME_NUMBER_STARTING_WITH_8()
to create the revision string (as requested in the other libebook bug...)

The revision string is stored as an "X property" of the main calendar component
and the revision is 'bumped' any time the calendar is modified.

The new commit on openismus-work-master:

commit 0c4285ba3e97137bef93e7a03d9cb655f5351ea6
Author: Tristan Van Berkom <tristan.van.berkom@gmail.com>
Date:   Tue Nov 22 17:58:30 2011 +0900

And the test case has also been updated:

commit bc043ce8c152ca4468cc80ae9fda29dde5f3aa53
Author: Tristan Van Berkom <tristan.van.berkom@gmail.com>
Date:   Thu Aug 4 21:32:09 2011 -0400


These are in fact the last 2 commits left on the branch...
Comment 7 Milan Crha 2011-11-22 15:39:05 UTC
Thanks, it looks good and is basically it, only with little issues:
a) change ECAL_REVISION_X_PROP to "X-EVOLUTION-DATA-REVISION", because it's
   the correct name for the X property and because otherwise you can get:
      CREATED;VALUE=X:2011-11-22T14:56:33.727731Z(1)
   instead of the revision property
b) typo in ensure_revision(), there should be ICAL_X_PROPERTY,
   instead of ICAL_X_COMPONENT
c) seeing how many times the bump_revision() is called, and always before
   the save() function, what about adding a gboolean parameter to the save()
   function, saying "do_bump_revision"?
d) I agree with moving CLIENT_BACKEND_PROPERTY_REVISION to e-client.h, but not
   to duplicate it in both e-cal-client.h and e-book-client.h. It's enough to
   have it in e-client.h only (same as the define for capabilities is not
   duplicated between EClient descendants).

And that's it, as you see, only a little polishing.
Comment 8 Tristan Van Berkom 2011-11-23 10:22:51 UTC
Created attachment 201980 [details] [review]
Patch to add revision backend property to ECal [take 2]

Same patch with the added polishing requested by Milan.

Consequently the patch touches tests/libebook/client/test-client-get-revision.c
to use the new CLIENT_BACKEND_PROPERTY_REVISION define.

New commit on 'openismus-work-master' branch:

commit 25ddd82dfdfffbfc36ae8eb11ff4711aa29db8bb
Author: Tristan Van Berkom <tristan.van.berkom@gmail.com>
Date:   Tue Nov 22 17:58:30 2011 +0900
Comment 9 Milan Crha 2011-11-23 11:46:32 UTC
That's it, thanks. Only replace those two spaces in front of bump_revision (cbfile); with one tab and commit to master.
Comment 10 Tristan Van Berkom 2011-11-29 12:08:59 UTC
Review of attachment 201980 [details] [review]:

Eeek I fixed the whitespace problem and pushed this almost a week ago and
forgot to close the bug...

Closing now sorry for the latency...
Comment 11 Tristan Van Berkom 2011-11-29 12:10:01 UTC
Committed as:

commit 9597173bbc19a81e53b2e353a7cf634ca2b1e11c
Author: Tristan Van Berkom <tristan.van.berkom@gmail.com>
Date:   Tue Nov 22 17:58:30 2011 +0900