[prev in list] [next in list] [prev in thread] [next in thread] 

List:       sqlite-users
Subject:    Re: [sqlite] Feature request
From:       Simon Slavin <slavins () hearsay ! demon ! co ! uk>
Date:       2009-05-30 18:26:12
Message-ID: FA7E0B24-E699-4B4C-94C6-02FBD070B69C () hearsay ! demon ! co ! uk
[Download RAW message or body]


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

[prev in list] [next in list] [prev in thread] [next in thread]