> Exposing the sqlite3 database to the users/plugins of the EBookSqlite is the > simple thing, while hiding it in the background doesn't fix anything. I still > can > open the table on my own, by getting the path from the backend (basically > construct it the same way the backend does), and then do whatever I want with > any of the tables there. This makes me believe that any "protection" on the > EBookSqlite side is useless and doesn't worth the complexity of the code.
Hi I'm attaching my first version of changes needed to implement database change log (it's based on openismus-work-3.8 branch as it was easier for me to test it - I cannot build master version for my target platform due to not met dependencies - but there shouldn't be much difference for master). I've added couple of additional functions to EBookSqlite, because I cannot retrieve old contacts from plugin using public functions from EBookSqlite, because they are using internal lock, which is already taken by function which is calling plugin hook, so basically I added non locking versions of this functions and made them internal (making them public make be dangerous), so old contacts need to be retrieved inside EBookSqlite before calling plugin hook. What do you think about this proposal ? Bye, Mateusz Intel GmbH Dornacher Strasse 1 85622 Feldkirchen/Muenchen, Deutschland Sitz der Gesellschaft: Feldkirchen bei Muenchen Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk Registergericht: Muenchen HRB 47456 Ust.-IdNr./VAT Registration No.: DE129385895 Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052
sqlite_changelog.patch
Description: sqlite_changelog.patch
_______________________________________________ evolution-hackers mailing list evolution-hackers@gnome.org To change your list options or unsubscribe, visit ... https://mail.gnome.org/mailman/listinfo/evolution-hackers
