Re: [Tracker] Support in Tracker for ultra-new Evolution installs that use SQLite for the summary format
- From: Carlos Garnacho <carlos imendio com>
- To: Philip Van Hoof <spam pvanhoof be>
- Cc: Ivan Frade <Ivan frade nokia com>, Evolution Hackers <evolution-hackers gnome org>, Tracker mailing list <tracker-list gnome org>
- Subject: Re: [Tracker] Support in Tracker for ultra-new Evolution installs that use SQLite for the summary format
- Date: Wed, 17 Dec 2008 12:27:06 +0100
On Thu, 2008-12-11 at 17:34 +0100, Philip Van Hoof wrote:
This patch makes ultra-new Evolution installs work again with Tracker.
There's one problem and that is that the query will only find E-mails in
the INBOX folder. You can easily find the Query and figure out what the
The design that Carlos made assumes that for each folder there's a
"summary" file. In the new Evolution cache format there's just one
"folders.db" for each account.
I could do a generated UNION select after first doing "select * from
folders" on folders.db and then generating a query that includes all
folders. I just have not done this for now and instead I'm just using
INBOX and I'm neglecting the other folders.
This is NOT the same as the proposal that I am doing at (a). This is
instead a ad-hoc solution for the new situation (Evolution using SQLite
for the summaries). I find this solution rather nasty, to be honest.
For Carlos: I have also fixed a serious problem in evolution-pop.c,
which is by the way unaffected by Evolution's changes (and works, if you
just apply the patch that I included in this larger patch). The POP
support's get_message_metadata was not returning metadata.
Ugh, right. Tracker now compiles with a variety of compiler flags, so
this and other errors have been spotted and fixed in trunk
This was crashing my tracker-indexer (as seemingly my compiler was
putting "return 0x2" where the return was omitted, and the memory I have
at 0x2 didn't dereference TrackerModuleMetadata's members very well).
Please review and/or rework the patch.
I think I agree with Ivan here, it could be better done as a new
TrackerModuleFile implementation, the code to deal with DBs and
summaries look quite unrelated (perhaps some functions should be moved
to evolution-common.[ch]), and it would help maintenance.
In src/tracker-indexer/modules/evolution.c you can see the code that
returns the appropriate TrackerModuleFile for the currently scanned mail
store, so you could hook there the implementation for newer evolution
] [Thread Prev