> Le 9 mai 2017 à 15:02, Simon Slavin <slav...@bigfraud.org> a écrit : > > On 9 May 2017, at 7:23am, Gwendal Roué <gwendal.r...@gmail.com > <mailto:gwendal.r...@gmail.com>> wrote: > >> As a reminder, I intend to use the authorisation system in order to tell if >> a statement has an opportunity to impact on another statement, as a support >> for a general database observation feature. > > I’ve read your proposed mechanism. Providing support for all those callbacks > looks like it would considerably slow down SQLite.
Observation is an opt-in service. The user decides which queries are observed. I haven't done any benchmark yet. Still, I care about performance, and GRDB is the fastest wrapper in its category: https://github.com/groue/GRDB.swift/wiki/Performance. Database observation is such an awesome service I could pay a little bit for it, though. If performance hit is too high (yet to be measured), then the user can still send change notifications in another way. > How are you going to handle TRIGGERs ? The authoriser analyses each > statement individually. It will not tell you everything that’s in the > TRIGGER until it decides to execute those statements. That's a very good question. I have indeed to think about triggers, and also foreign key cascades. Unless I'm wrong, cascades can be handled through foreign keys introspection. Triggers, on the other side... Well, if triggers can not be handled, then the documentation will have to tell it in an explicit way: this does not invalidate the whole idea. > I don’t think the authorisation system can be efficiently used in this way. > If you’re analysing statements speculatively you’ll get more information out > of EXPLAIN. Thanks for the suggestion. Even if EXPLAIN can give enough information, this does not invalidate the information provided by authorizer callbacks. Gwendal _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
