Re: [Evolution-hackers] Contacts database modifications history



On Thu, 2014-04-24 at 13:51 +0000, Potrola, MateuszX wrote:
On Wed, 2014-04-23 at 16:08 -0400, Tristan Van Berkom wrote:
This is my prerogative and I can accept that it is not shared with the
maintainers of EDS, nevertheless I would still like to caution against
opening up the SQL tables owned by EBookSqlite to be shared with
plugins (it may take a little more time in the beginning to flesh out
a well defined interactive API that satisfies the needs of plugins,
but this will pay off in better long term stability, anyway this is my opinion).

I agree with you, plugins should not make assumptions about the content of
sqlite database. This needs to be documented clearly.

However, the goal is not to let plugins access the existing tables.
Instead, the goal is to let plugins create their own custom tables and update
them as part of the same transaction that EBookSqlite uses to update its own
tables. Name clashes need to be avoided, but that is a minor issue. We might
also want to add hooks for DB updates and locale changes.
I think that we can still create solution where internal tables from
EBookSqlite will be protected from accessing from plugins and all
queries will be run in the same transaction (which is most important
part for us).
Shared transaction across databases may be possible by using sqlite
ATTACH command. Plugins can create their own databases and ask
EBookSqlite to attach them to the one used by EBookSqlite, providing
some names that will identify them (this name will have to be
prepended to each table name when making query).

For this to work we still need to grant the plugin access to the sqlite
connection of the EBookSqlite database. All that we gain is that sqlite
helps a bit with resolving table name conflicts and that data gets
separated into more files (not necessarily an advantage).

Note that we still need to be careful about name conflicts, because
sqlite will pick the most recently attached table first if the table
name is not unique (http://www.sqlite.org/draft/lang_attach.html). In
other words, a plugin that happens to pick the same name as core
EBookSqlite will cause EBookSqlite to use the plugin's table instead.

We also loose the option to turn on WAL
(http://www.sqlite.org/draft/wal.html) because atomicity is not
guaranteed for attached databases. EDS might not use WAL at the moment,
but it would be an interesting exercise to run benchmarks with it
enabled.

Bottom line is that I don't see ATTACH as a viable solution for the
problem, in contrast to clearly documenting the table naming convention
and the boundary between 
EBookSqlite and plugin.

Bye, Patrick




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]