Darren,
Are you asking for a pragma integrity_check (which already exists) or are
you just wanting to verify the magic string at the beginning of the file?
Personally, I think it would be nice to have some means to say "Open this
file if it already exists and is an sqlite file: Don't create it if it
doesn't exist". I'm not sure I've found any cases where it is entirely
necessary, though.
Benjamin.
Darren Duncan <[EMAIL PROTECTED]>
08/10/2004 06:38 AM
Please respond to sqlite-users
To: [EMAIL PROTECTED]
cc:
Subject: [sqlite] new Ticket 949: add user-level test for file validity
FYI, I added the following ticket today. A copy is also here on the
list in case any discussion is necessary. (No replies may be taken
as consensus.) -- Darren Duncan
-----------------------------
Type: new
Version: 3.0.7
Status: active
Created: 2004-Oct-07 20:28
Severity: 3
Last Change: 2004-Oct-07 20:28
Priority: 3
Subsystem: Unknown
Assigned To: anonymous
Creator: anonymous
Resolution: Pending
Please add a one-step user-level test that one can invoke to
determine whether a file is a valid SQLite database. I can
understand open() not doing this automatically for performance
reasons, but there should be an alternative for users who want
behaviour as if it did. Performing a dummy select, the current
recommended solution to performing the test, is a very in-elegant
solution.
1. One alternative option I suggest adding a new stateless function
whose prototype looks like open() but has a name like "is_a_database"
or "validate_file" or what-have-you. Conceptually, what this
function could do is: open(), perform smarter replacement for dummy
select, close(); it would return the code for OK if the given file is
a valid database, and the appropriate SQLite error code if it is not.
2. An alternative solution, which could be done instead of or in
addition to the above, is a stateful function that you invoke on the
structure that open() returns. A user would invoke it right after
open(); they then explicitly call close() if testing the file was all
they wanted to do, or otherwise they keep it open and do whatever
they were going to do, but now they can be confident that any actual
work will not fail due to it being an invalid file.
3. A third solution would be to add an optional boolean argument to
open() which, if set true, would cause open() to perform the test in
question.
I suggest that option 2 may be the best one, for multiple reasons,
including both flexability, future extensibility, performance,
simplicity, and non-interference with other future design plans.
I believe that making this change will result in better
self-documenting code for users than the current work-around is.
I also believe that this change should be very simple to do,
especially if you pick option 2.
I also request that you implement this in the 2.8.x branch as well,
so that applications which can possibly work with both versions of
SQLite databases have the same simplicity of testing.
Finally, something which you don't have to do, but that my
recommended change would make it easier for someone else to do, is
that an application could quickly scan a file system (or a single
directory at least) and quickly determine which files in it are
SQLite databases and which aren't, a list of valid ones it would
return for a user or program to select from.
