## How to generate history.N.sql files using a Chromium build.
On a Linux build:
1. Build the `sqlite_shell` target. This will build the [SQLite CLI].
$ ninja -C out/Debug/ sqlite_shell
2. Run Chrome/Chromium with a fresh profile directory and immediately quit. It
doesn't really matter how long you run it, but there'll be less work for you
if you quit early.
$ out/Debug/chrome --user-data-dir=foo
3. Locate the `History` file in the user-data-dir directory; e.g., `foo/Default/History`.
4. Dump the `History` database into a text file:
$ echo '.dump' | out/Debug/sqlite_shell foo/Default/History > history.sql
5. Manually remove all `INSERT INTO` statements other than the statements
populating the `meta` table.
<!-- This section adapted from comment in history_backend_db_unittest.cc. -->
In the past, we only added a history.57.sql file to the repo while adding a
migration to the NEXT version 58. That's confusing because then the developer
has to reverse engineer what the migration for 57 was.
If you introduce a new migration, add a test for it in `HistoryBackendDBTest`,
and add a new `history.N.sql` file for the new DB layout so that
`HistoryBackendDBTest.VerifyTestSQLFileForCurrentVersionAlreadyExists` keeps
passing. SQL schemas can change without migrations, so make sure to verify the
`history.N-1.sql` is up-to-date by re-creating. The flow to create a migration
`N` should be:
1. There should already exist `history.N-1.sql`.
2. Re-create `history.N-1.sql` to make sure it hasn't changed since it was
created.
3. Implement your migration to version `N`.
4. Add a migration test above the line labeled `NEW MIGRATION TESTS GO HERE`,
beginning with `CreateDBVersion(n-1)` and ending with
`ASSERT_GE(HistoryDatabase::GetCurrentVersion(), n);`
5. Create `history.N.sql`. Then run `git cl presubmit` to get a command to add
the new file to a filelist in this directory.
[SQLite CLI]: https://www.sqlite.org/cli.html
Codebase Browser
chromium