Implement sql::Connection::Raze() in terms of sqlite3_backup API.

sql/connection.h

 // Copyright (c) 2011 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #ifndef SQL_CONNECTION_H_
 #define SQL_CONNECTION_H_
 #pragma once
 
 #include <map>
 #include <set>
@@ skipping 163 matching lines @@
   // organically.
   //
   // This function assumes your class is using a meta table on the current
   // database, as it openes a transaction on the meta table to force the
   // database to be initialized. You should feel free to initialize the meta
   // table after calling preload since the meta table will already be in the
   // database if it exists, and if it doesn't exist, the database won't
   // generally exist either.
   void Preload();
 
+  // Raze the database to the ground.  This approximates creating a
+  // fresh database from scratch, within the constraints of SQLite's
+  // locking protocol (locks and open handles can make doing this with
+  // filesystem operations problematic).  Returns true if the database

[Greg Billock, 2012/03/31 01:23:50]

Does this mean it won't necessarily work? It seems like this would be used in
extreme situations, so wouldn't that mean it should take steps to try to make
sure that collisions get nuked as well?

[Scott Hess - ex-Googler, 2012/04/04 01:28:25]

My broad background with this change is:
A) corruption isn't that common in the first place, and has varied causes, which
make this hard to test for real.
B) we have a baseline presumption that SQLite's core operations like opening
journal files and writing pages are appropriate.

Tracing through the SQLite code, there are places where this code can fall down,
and for the most part resolving the problem in those cases probably requires
changes in the caller, or additional gruntwork to track down what's really
happening (by adding histograms or DumpWithoutCrash() calls or something).  So
this CL aims to provide a best-effort, I-think-this-should-work-well starting
point, which can be built on.

My expectation is that we'll find that this doesn't work in a tiny number of
cases, and that they'll be "I have no idea what we can do about that" types of
cases.  Like "profile not writable" or "disk is horribly hosed".  If there's a
systemic case, like Database X turns out to have two writers instead of the
expected one, then we'll (hopefully) notice and drill down and fix the problem.

[Greg Billock, 2012/04/04 19:49:21]

Sounds good. I don't know if any of that's worth mentioning in the comment.
Since you've already written it, perhaps so...

On 2012/04/04 01:28:25, shess wrote:

+  // was razed.
+  //
+  // false is returned if the database is locked by some other
+  // process.  RazeWithTimeout() may be used if appropriate.

[Greg Billock, 2012/03/31 01:23:50]

What's the use case for that kind of call?

[Scott Hess - ex-Googler, 2012/04/04 01:28:25]

Most (all?) profile databases are exclusive-access, so they should NEVER receive
SQLITE_BUSY and Raze() should work.  Web SQL databases can be opened in multiple
renderers, in which case SQLITE_BUSY must be expected and handled.

[Greg Billock, 2012/04/04 19:49:21]

Do you envision using this most typically for WebSQL disaster recovery? My
mental image was this was for profile DBs, but perhaps that's completely off.

On 2012/04/04 01:28:25, shess wrote:

[Scott Hess - ex-Googler, 2012/04/04 20:28:52]

Mostly it's for profile dbs, but I believe websql has a case where the database
needs to be deleted, except there they don't have exclusive access so they have
to wait around for things to clear.  In the Gears days we had a similar problem,
where many processes could have connections, so it was unclear what to do when
corruption was detected.  We added sqlite3_poison() which broke the database in
a transactional fashion, so that on next access all the other connections broke
and reset.

+  //
+  // NOTE(shess): Raze() will DCHECK in the following situations:
+  // - database is not open.
+  // - the connection has a transaction open.
+  // - a SQLite issue occurs which is structural in nature (like the
+  //   statements used are broken).
+  // Since Raze() is expected to be called in unexpected situations,
+  // these all return false, since it is unlikely that the caller
+  // could fix them.
+  bool Raze();
+  bool RazeWithTimout(base::TimeDelta timeout);
+
   // Transactions --------------------------------------------------------------
 
   // Transaction management. We maintain a virtual transaction stack to emulate
   // nested transactions since sqlite can't do nested transactions. The
   // limitation is you can't roll back a sub transaction: if any transaction
   // fails, all transactions open will also be rolled back. Any nested
   // transactions after one has rolled back will return fail for Begin(). If
   // Begin() fails, you must not call Commit or Rollback().
   //
   // Normally you should use sql::Transaction to manage a transaction, which
@@ skipping 207 matching lines @@
   // This object handles errors resulting from all forms of executing sqlite
   // commands or statements. It can be null which means default handling.
   scoped_refptr<ErrorDelegate> error_delegate_;
 
   DISALLOW_COPY_AND_ASSIGN(Connection);
 };
 
 }  // namespace sql
 
 #endif  // SQL_CONNECTION_H_