Gerrit Code Review

What is notedb?

Notedb is the successor to ReviewDb: a replacement database backend for Gerrit. The goal is to read code review metadata from the same set of repositories that store the data. This allows for improved atomicity, consistency of replication, and the creation of new features like federated review and offline review.

This document describes the state of migration (not necessarily completely up to date), the tasks that remain, and notes on some of the challenges we‘ve encountered along the way. This document is not a full design document for notedb; if you’re that curious, bug dborowitz and he will help you out.

Finally, this document is for core developers. If you are a casual user of Gerrit looking for documentation, you've come to the wrong place.

Root Tables

While ReviewDb has a lot of tables, there are relatively few “root” tables, that is, tables whose primary key's get!ParentKey() method returns null:

  • Change: subtables ChangeMessage, PatchSet, PatchSetApproval, PatchSetAncestor, PatchLineComment, TrackingId
  • Account: subtables AccountExternalId, AccountProjectWatch, AccountSshKey, AccountDiffPreference, StarredChange
  • AccountGroup: subtables AccountGroupMember

TODO(dborowitz): Document other minor tables, audits, etc.

For each root entity in each of these tables, there is one DAG describing all modifications that have been applied to the change over time. Entities DAGs are stored in a repository corresponding to their function:

  • Change: stored in refs/changes/YZ/XYZ/meta in the destination repository
  • Account: stored in refs/accounts/YZ/XYZ/meta (TBD) in All-Users
  • AccountGroup: stored in TBD in All-Projects

Most of this document focuses on Change entities, partly because it‘s the most complex, but also because that’s where most effort to date has been focused.

Changes: What's Done

Current progress, along with some possibly-interesting implementation notes.

  • ChangeMessages: Stored in commit message body. Currently the subject of the commit message contains a machine-generated-but-readable summary like “Updated patch set 3”; we might decide to eliminate this and just use the ChangeMessage.
  • PatchSetApprovals: Stored as a footer “Label: Label-Name=Foo”. Instead of storing an implicit 0 review for reviewers, include them explicitly in a separate Reviewer footer. Freeze labels at submit time along with the full submit rule evaluator results using “Submitted-with”.
  • PatchLineComments: The only thing thus far actually stored in a note, on the commit to which it applies. Drafts are stored in a per-user ref in All-Users.
  • TrackingId: Killed this long ago and use the secondary index. (Just reminded myself I need to rip out the gwtorm entity.)
  • Change: Started storing obvious fields: owner, project, branch, topic.
  • PatchSet: Storing IDs and created on timestamps right now, not reading from it yet.

Changes: What Needs to Be Done

  • PatchSetAncestors: Replace with a persistent cache, which should probably be rebuilt in RebuildNotedb.
  • PatchSet: Draft field. (Someday I think we should replace Draft with WIP, but I digress.)
  • Change: Kill more fields. Actually implement reading from changes; see challenges section.
  • Some sort of batch parser. If we get 100 changes back from a search, sequentially reading the DAG for each of those might take a while.
  • Benchmark and optimize the heck out of the parsers. Let's say a target is 1ms per change DAG. Related, we may also need to disable (eager) parsing of certain fields, if we can prove with benchmarks that they are problematic. (We already do this for PatchLineComments, to avoid having to read anything but commits in the common case.)

JGit Changes

  • Teach JGit to pack notedb refs in a separate pack file from everything else. We don't want to hurt locality within the main pack by interleaving metadata commits.
  • Teach JGit to better handle many small, separate commit graphs in the packer. Ordered chronologically, notedb metadata will be spread across a large number of separate DAGs. We will get better kernel buffer cache locality by clustering all commits in each disconnect DAG together. (But this may also hurt batch parsing; see above.)

Challenges

TODO