On 10 may 2004, at 12:47, D. Richard Hipp wrote:
The tricky part is knowing when any change has occurred to the database at all. If you have a single process that is doing all the changes, then this is simple. Just build a wrapper around your SQLite access routines that sends a signal after every operation. But if you have multiple processes updating the same database file, you'll have to use some kind of polling mechanism. Polling is not as bad as it might seem at first, though. On a typical workstation, you can do something like
SELECT * FROM ChangeLog;
about 10 times per second with no measurable CPU load. Even so, it is better if you have a single process doing the updates.
Even though it's not cross-platform, I'd like to give a hint to those developers using SQLite in their Cocoa projects.
Instead of polling, one can use NSDistributedNotificationCenter and post the notification like this:
[[NSDistributedNotificationCenter defaultCenter] postNotificationName: @"kSQLiteDatabaseInsert" object:nil];
You can use NSNotificationCenter is you want to restrict the notification within the app. Other open apps will not receive the notification.
Of course, you may want to track different ops, such as @"kSQLiteDatabaseUpdate" or @"kSQLiteDatabaseDelete". The you'll need to addObserver in the object that needs to be informed. The advantage to use NSDistributedNotificationCenter is that polling is removed and you get notified whenever the notification takes place. Since it's distributed, all processes running locally will get notified.
Regards,
-- Tito
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
