On Fri, Jan 21, 2011 at 8:27 PM, James Berry <[email protected]> wrote:
> I ran into an interesting problem today having to do with a left-over > journal file. > > When I first initialize my app, my general strategy is this: > > - Delete src.db, tmp.db, dst.db > - Copy a static copy of my database (src.db) to a well-known > temporary place (tmp.db). > - Make some changes to the database (add some indexes, etc) > - If everything has succeeded, copy tmp.db -> dst.db > > The theory (was) that if there are any crashes during the initialization > process, etc, that dst.db will never be valid and initialization will start > from ground zero on the next launch. > > This fails, for the simply reason that if a crash occurs, a single file is > left-over at the next startup: dst.db-journal. And when the journal is > there, in conjunction with a fresh copy of the src.db, sqlite fails in > various manners, as might (or might not) be expected. > > That background out of the way, three questions: > > (1) Is there any API I can/should use to predictably get the name of > the journal file so that I can delete it, without "knowing" what is should > be? > The name of the journal is always the name of the original database file with either "-journal" or "-wal" appended. Delete those two files when you delete the original database and you are always safe. To change the journal filenames in any way would result in an incompatible file format, since it would mean that newer versions of SQLite would not be able to recover from crashes on older versions of SQLite. We work really, really hard to avoid incompatibilities, so you may safely assume that the journal filenames will remain unchanged. > > (2) Are there any changes that can/should be made to sqlite3 so that > it can identify the bogus journal in this scenario and discard it? > We've thought about that before, but never could come up with a reasonable suggestion. > > (3) Should there be a flag to open_v2, or something, that tells it > to discard any extant journal? > Having that option on open_v2() would just confuse people into actually using it, which means they would more often end up deleting hot journal files that they really needed for crash recovery. Such a flag would result in far more problems that it solves, I believe. > > Thanks, > > James > _______________________________________________ > sqlite-users mailing list > [email protected] > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > -- D. Richard Hipp [email protected] _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
