IMO, all that, plus the fact that you have an easy roll back mechanism. Anything that needs to be put in the database is external to the pristine database. Lock the database with a transaction, fill up the journal, the power goes out, your pristine database isn't touched. Just whatever happens in the journal might get damaged due to caching at the memory or HDD level.
On Wed, Feb 24, 2016 at 8:50 AM, Paul <devgs at ukr.net> wrote: > Good point! > > I can assume that the problem would be a sparsity of database file. If you > mix normal pages and journal then database will be fragmented. > > You can't avoid it. Even if you start writing journal at the end of file, > hoping that you can later truncate it at commit, there is no way to know > how far, from the current end of file, should journal file start. At some > point, if transaction is big enough, new allocated pages in database will > hit the spot in file where journal pages are. > > > 24 February 2016, 14:53:55, by "Simon Slavin" <slavins at bigfraud.org>: > > > In case you're new to this group, please understand that I'm > experienced with SQLite and I understand how it works and how it uses > journal files. > > > > Can someone explain to me -- or point at a web page which does -- why a > separate journal file is needed. Why can't the information which SQLite > stores in a journal file be put in the database file ? Given how SQLite > structures its database files this would presumably mean that the main > database would have journal pages as well as table and index pages. Or > that there would be 'stable' table and index pages and 'journal' table and > index pages. > > > > Simon. > > _______________________________________________ > > sqlite-users mailing list > > sqlite-users at mailinglists.sqlite.org > > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users > > > _______________________________________________ > sqlite-users mailing list > sqlite-users at mailinglists.sqlite.org > http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users >
