On Fri, Feb 17, 2012 at 1:02 PM, Richard Hipp <d...@sqlite.org> wrote: > On Fri, Feb 17, 2012 at 3:52 PM, Marc L. Allen > <mlal...@outsitenetworks.com>wrote: >> My concept of always consistent is a.. for lack of a better term... >> virtual concept. That is, anytime anything accesses the database, as a >> database, that database is always consistent. > > That is a good way to look at it. Or, a similar approach is to consider > that the database consists of both the main database file and the > hot-journal, but that the database must be transformed into just the > database file without the hot journal before it can be used.
In this case SQLite could read the entire journal to build an index, and then preferentially populate the pcache from the journal when it has the page. I do think that a system which is designed in such a way that this would be helpful might be poorly designed, so it would definitely make sense for it to be included only by compile-time option. That said, right now SQLITE_OPEN_READONLY implies that the file will be opened with O_RDONLY (at least for os_unix.c), which means that even if you knew that there were no other writers possible, and you wanted to guarantee that your process not write to the file, you would be required to open read-write and somehow provoke the repair process. It might make sense to have a way to call sqlite3_open_v2() in a way such that this is hidden, so it opens a read/write file descriptor to rollback using the hot journal, and only returns a sqlite3 handle when things are back in a working state. It wouldn't prevent another writer from crashing in the future, like you said. Maybe it could additionally guarantee exclusive locking, so that nobody else can muck with things? -scott _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
