Re: [sqlite] Most efficient way to detect on-disk change

Thank you all! I really have to do a thorough read of all the pragmas, there are so many useful things in there! The user version sounds exactly like what I should be using for storing the db version, and presumably the data_version is a little faster still than reading the user version. @Keith,

Re: [sqlite] Most efficient way to detect on-disk change

On 11/08/2017 03:55 PM, Dominique Devienne wrote: On Wed, Nov 8, 2017 at 7:45 AM, Dan Kennedy wrote: On 7 Nov 2017, at 6:53pm, David Raymond wrote: I think pragma data_version is what you're looking for.

Re: [sqlite] Most efficient way to detect on-disk change

On Wed, Nov 8, 2017 at 7:45 AM, Dan Kennedy wrote: > On 7 Nov 2017, at 6:53pm, David Raymond wrote: >> >> I think pragma data_version is what you're looking for. >>> http://www.sqlite.org/pragma.html#pragma_data_version >>> >> > I think it's the

Re: [sqlite] Most efficient way to detect on-disk change

On 11/08/2017 02:41 AM, Simon Slavin wrote: On 7 Nov 2017, at 6:53pm, David Raymond wrote: I think pragma data_version is what you're looking for. http://www.sqlite.org/pragma.html#pragma_data_version An excellent solution, though there’s a /caveat/. From the

Re: [sqlite] Most efficient way to detect on-disk change

On 7 Nov 2017, at 11:12pm, Jens Alfke wrote: > On Nov 7, 2017, at 2:39 PM, Keith Medcalf wrote: > >> What advantage does your third-level (application) cache provide that is not >> provided by the two lower level caches? > > You’re being

Re: [sqlite] Most efficient way to detect on-disk change

> On Nov 7, 2017, at 2:39 PM, Keith Medcalf wrote: > > What advantage does your third-level (application) cache provide that is not > provided by the two lower level caches? You’re being presumptuous here. It’s pretty common for presentation-level data to be very

Re: [sqlite] Most efficient way to detect on-disk change

On Tue, 07 Nov 2017 18:07:42 + Wout Mertens wrote: > I'm working with a db that's only written to in transations, and each > transaction increases a db-global version counter. > > This means that I can cache all reads, unless the version changed. > > What would be

Re: [sqlite] Most efficient way to detect on-disk change

in linux inotify - http://man7.org/linux/man-pages/man7/inotify.7.html in windows FindFirstChangeNotification/FindNextChangeNotification https://msdn.microsoft.com/en-us/library/windows/desktop/aa365261(v=vs.85).aspx if you wait for an actual change before checking to see if there really was a

Re: [sqlite] Most efficient way to detect on-disk change

So you are caching data at the application level that is cached at the database page cache level which is cached in the Operating System file cache that lives in a file residing on disk -- effectively storing three copies of the data in memory. What advantage does your third-level

Re: [sqlite] Most efficient way to detect on-disk change

> On Nov 7, 2017, at 11:41 AM, Simon Slavin wrote: > > So when you convert your code to use multiple processes, they must all use > the same connection for this to work properly. No; it just means each process will track its own data-version value based on its own

Re: [sqlite] Most efficient way to detect on-disk change

On 7 Nov 2017, at 6:53pm, David Raymond wrote: > I think pragma data_version is what you're looking for. > http://www.sqlite.org/pragma.html#pragma_data_version An excellent solution, though there’s a /caveat/. From the original post: > Right now everything's a

Re: [sqlite] Most efficient way to detect on-disk change

I think pragma data_version is what you're looking for. http://www.sqlite.org/pragma.html#pragma_data_version -Original Message- From: sqlite-users [mailto:sqlite-users-boun...@mailinglists.sqlite.org] On Behalf Of Wout Mertens Sent: Tuesday, November 07, 2017 1:08 PM To: SQLite mailing