Google Git
Sign in
chromium/chromium/src/HEAD/./components/test/data/history
tree: a85a3b33db92ec195cedf9bd39d3757974ca15e8
  1. thumbnail_wild/
  2. Favicons.v3.sql
  3. Favicons.v4.sql
  4. Favicons.v5.sql
  5. Favicons.v6.sql
  6. Favicons.v7.sql
  7. Favicons.v8.sql
  8. Favicons.v9.sql
  9. history.22.sql
  10. history.26.sql
  11. history.27.sql
  12. history.28.sql
  13. history.29.sql
  14. history.30.sql
  15. history.31.sql
  16. history.32.sql
  17. history.38.sql
  18. history.39.sql
  19. history.40.sql
  20. history.41.sql
  21. history.42.sql
  22. history.43.sql
  23. history.44.sql
  24. history.45.sql
  25. history.46.sql
  26. history.47.sql
  27. history.48.sql
  28. history.49.sql
  29. history.50.sql
  30. history.52.sql
  31. history.53.sql
  32. history.54.sql
  33. history.55.sql
  34. history.56.sql
  35. history.57.sql
  36. history.58.sql
  37. history.59.sql
  38. history.60.sql
  39. history.61.sql
  40. history.62.sql
  41. history.63.sql
  42. history.64.sql
  43. history.65.sql
  44. history.66.sql
  45. history.67.sql
  46. history.68.sql
  47. history.69.sql
  48. history.70.sql
  49. History_with_starred
  50. HistoryNoDuration
  51. HistoryNoSource
  52. OWNERS
  53. README.md
  54. TopSites.v1.sql
  55. TopSites.v2.sql
  56. TopSites.v3.sql
  57. TopSites.v4.sql
  58. TopSites.v5.sql
  59. unit_tests_bundle_data.filelist
  60. unit_tests_bundle_data.globlist
components/test/data/history/README.md

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.

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.