JJZolx;555733 Wrote: > I take it that the only thing that the plugin does is execute SQL > queries following a scan. Using your own example, for SbS 7.6 it's > probably going to be necessary to allow the user to enter two sets of > queries - one for MySQL and one for SQLite, just in case the SQL syntax > is different. The user can enter any 'ol SQL statement he/she pleases. The only thing SQLite specific in the code at this point is the addition of the psrepace() function to allow regex in UPDATEs. If the plugin sees that the DB engine isn't SQLite, that function is unavailable.
I've got to believe that most folks won't be in the habit of switching DB engines on a daily basis. But, yes, if a user does switch, they may have to rewrite some of their queries if they're using statements that are SQLite or MySQL specific. Personally, the way I'd work around that is to keep backups of the postscan.prefs file and swap them when changing the DB. A Primitive-Pete approach, but effective. JJZolx;555733 Wrote: > With 7.6, does it run your queries following automatic scans triggered > by inotify? What about after the scan that 7.6 now does at startup? > Or the scans that are scheduled at N minute intervals on systems that > don't support inotify? Does it run only if new content is found by > these scans? At this point, all it does is subscribe to the 'rescan' and 'wipecache' events and then react to the notification. I have the inotify stuff disabled on my system, so I haven't tested this. But, assuming that an inotify-triggered scan posts a 'rescan' notification upon completion, the PostScan queries will get run. I have seven PostScan queries cued up with my setup and running them all (even on a low-powered Atom box) takes only about a second. But then, all my queries are working against GENRES, which is a very small table. If the user wants to run against TRACKS, that will, of course, entail more time. But the UI should still be perfectly usable during the scans. I'll be surprised if this proves to be a problem. The trick for the users will be to construct queries (and correctly order them) so that multiple runs (i.e. applying fixes to things already fixed) don't have deleterious effects. -- gharris999 ------------------------------------------------------------------------ gharris999's Profile: http://forums.slimdevices.com/member.php?userid=115 View this thread: http://forums.slimdevices.com/showthread.php?t=79778 _______________________________________________ plugins mailing list plugins@lists.slimdevices.com http://lists.slimdevices.com/mailman/listinfo/plugins
