pub fn migrate_layout(
root: &Path,
options: LayoutMigrationOptions,
) -> Result<LayoutMigrationResult, DatabaseError>Expand description
Moves a database between the flat and nested on-disk arrangements.
Idempotent: a database already in the target arrangement, under the target document name,
reports changed: false and moves nothing. Never automatic — in a repository this is a visible
change to tracked files, so it has to be asked for. Only files the database accounts for are
moved; anything else in the root is reported in unclaimed and left alone.
The directory is held under the writer lock for the length of the move (see [hold_for_move]),
so nothing here races a writer that has the directory open. The lock is released before the
directories the move emptied are removed, because in a nested database the lock file itself
lives in one of them.
A format-1 database is moved without being migrated: its <table>.schema.json files travel with
it and its manifest is left in format 1, so what open() says about it afterwards is exactly
what it said before.
@param root the database directory
@param options the arrangement to move into, the document names on either side of the move, and
whether to only report the plan
@returns what was moved, or would be moved under dry_run