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 _______________________________________________ evolution-hackers mailing list [email protected] To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
