I read through the header after Simon's request, and saw the data change counter he mentions. What I wasn't sure about is whether this number gets reset during a rollback. For example, you start a transaction, make some changes, some cache pages get flushed, and SQLite changes this number so that other processes know that the database has changed. In fact, SQLite may change this number anytime it changes pages in my local cache - not sure. The header word seems to be designed to prevent stale cache lookups.
If I rollback my changes, it would be unimportant for cache management whether the value rolled back also, but it would be important if the data didn't actually change for the value to roll back. Or, you could use the value as "data might have changed", but then it would be less useful for file synchronization. Jim On 5/30/09, Simon Slavin <slav...@hearsay.demon.co.uk> wrote: > > On 23 May 2009, at 3:32pm, Filip Navara wrote: > >> PRAGMA schema_version ... for the second case. > > Okay. Given that this does exactly what I want from one of my > requests, and given Jim Wilcoxson's point that adding a PRAGMA is > better than adding a function to the library, I can simplify my > feature request to asking for something like > > PRAGMA content_version OR PRAGMA data_version > > which returns the number stored in bytes 24 to 27 of the header. This > should have only a small impact on library size, and require very > little extra code since the number needs to be worked out anyway for > storage in the header. It should be useful for purposes associated > with synchronisation and journaling but it's mostly so that > applications which store some data outside SQL and some inside can > tell if they need to worry about something messing with their data. > > It doesn't matter to me whether a schema-change is considered a > content-change or not. I can sum the two in my own code if needed. > But the documentation should describe whether field-changes, or > COMMITs, or whatever is counted. > > I know I can read the file's header myself (and that's what my current > solution does) but this means I need to include file-handing libraries > in my library which I don't otherwise need. It's not a neat solution. > > Simon. > _______________________________________________ > sqlite-users mailing list > sqlite-users@sqlite.org > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- Software first. Software lasts! _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
