Hi L,
You seem to be after a theory rather than an actual helpful criterion - and Richard answered questions 1, 2 and 3 all in a single
statement as far as the criterion matters. To illuminate the theory is not really possible and presupposes a wealth of preceding
information that must be known - something I doubt anyone will want to re-type here.
To try my hand at summarising what I think you are asking and what I think really happens without too much detail (hoping others
will fill in where I may err):
SQLite has no direct control to a file, it operates at the other end of a VFS, which is much like a telephone conversation to
somebody you cannot see. It asks the VFS for a handle to a file, it suppplies that handle every time it requests a file operation.
The operations are mostly Open, Read, Write, Close and a few less important ones. It also stores a path to an opened DB file and
use this same mechanism for the journal files.
Specific to your question 1 : Even if it was set in stone (which it ain't) how SQLite starts a file connection, it still does not
mean the VFS will do it in the same way. This is not just theoretical differences, there are very existing differences on how OSX or
Windows or Linux or Android systems do this, nevermind all the custom VFSes used in the wild. So the answer becomes: "Who knows?" -
AND, as if that's not unspecific enough, - "It can change at a whim".
Question 2: SQLite requires the data this-side-of-the-vfs to be consistent and atomic, therefore it locks files as needed and you
cannot read a file in the middle of a write operation (I mean, what data will you be getting back? and will it be
half-old-half-new?). When moving/renaming files - some OS systems like Linux are very happy to keep VFS comms going to a file-handle
because the actual bytes on disk does not move, just a file-table reference to it, which you only really need as a lookup for
acquiring a new handle. On other systems notably Android and Windows, actual bytes might be moved in part, but regardless of whether
it is, just for the possibility thereof (and in the name of consistency with cross-volume moves), the VFS kills access to the file
once it is moved. SQLite has no control over this and is at the mercy of the operating system on the other side of the VFS. (but it
contains many checks and balances to ensure data stability regardless of VFS whims).
Question 3: Answered above really, but to recap - SQLite has no control over files directly, it communicates only with the VFS,
therefore ANYTHING that goes wrong will kill the access, whether it be a move on non-movable OS, or SQLite asking for a file in a
path (access or create) that no longer exists, or a number of other related possible issues, it's essentially unknown to SQLite and
cannot be known comprehensively, unless you single out an OS, and even then, it may change on a whim and can never be used as a
programmatic measure (but I don't think you were imagining it in this way anyway).
I hope this is slightly more illumiating than before. Sorry it can't be
definitive answers.
On 2013/11/29 17:59, L. Wood wrote:
Of course, Richard has already answered question 1 and that answer definitely
doesn't change.
Questions 2 and 3 now remain.
----------------------------------------
From: lwoo...@live.com
To: sqlite-users@sqlite.org
Date: Fri, 29 Nov 2013 15:21:51 +0000
Subject: Re: [sqlite] Your thoughts on these observations
Before answering my questions:
Please get rid of "rename" entirely in my post. Replace "rename/move" with just
"move".
Also, assume that whenever I move my main database file, the -journal file
always moves with it too.
I apologize for the confusion. My mistake. Sorry Richard.
I have made a few experimental observations and I would appreciate your
thoughts.
1.
_open() does indeed actually open the main database file. It is left open all
the way until _close(), when it is actually closed. Correct?
I ask because someone mentioned before that _open() doesn't really open the
file - that it only prepares the file for opening at a later time when open is
actually needed.
2.
If my SQL statements do nothing but read from the database (no writes), I can
rename/move the main database file any time I wish after _open() without any
problems whatsoever. Correct?
3.
If my SQL statements write to the database and I rename/move the main database
file just after _open(), the next call to _step() gives me the error
SQLITE_IOERR.
This happens NOT because the main database file has been renamed/moved. Correct?
Rather, this happens because the old path has been saved by SQLite for use by
the -journal files. The error happens because SQLite cannot match the -journal
file name and the main database file name (which has now changed). But here I'm
just guessing. Is this correct? If not, then why exactly does the error occur?
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
