On 11/08/2017 03:55 PM, Dominique Devienne wrote:
On Wed, Nov 8, 2017 at 7:45 AM, Dan Kennedy <danielk1...@gmail.com> wrote:
On 7 Nov 2017, at 6:53pm, David Raymond <david.raym...@tomtom.com> 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 opposite. For connection A, the value of "PRAGMA
data_version" does not change as a result of commits by connection A. It
changes if the db is modified by any other connection, regardless of
whether or not that other connection resides in a different process or not.
"The integer values returned by two invocations of "PRAGMA data_version"
from the same connection will be different if changes were committed to the
database by any other connection in the interim. The "PRAGMA data_version"
value is unchanged for commits made on the same database connection."
Hi Dan. So you confirm David's answer, provided OP also tracks change made
by the local connection, in addition to tracking pragma data_version?
That's right.
The original use case was an application-level cache of objects
associated with a single database connection. The cache should be
invalidated whenever the database is written. So the app would:
a) invalidate the cache whenever it wrote to the db, and
b) checked that "PRAGMA data_version" has not changed before using an
object from the cache (and invalidating the entire cache it if it had).
I guess the logic was that the app could implement more fine-grained
cache invalidation in (a) if required.
Dan.
I just want to make sure I understand your answer correctly. Thanks, --DD
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
