pub struct LayoutMigrationOptions {
pub to: Option<LayoutKind>,
pub from_metadata_file: Option<String>,
pub from_manifest: Option<String>,
pub metadata_file: Option<String>,
pub manifest_file: Option<String>,
pub dry_run: bool,
pub lock: LockMode,
}Expand description
Which arrangement to move a database into, and under what name to leave its metadata document.
Every member is optional, and Default is what migrateLayout(root) does in TS: move into the
nested arrangement, keep the document’s name, take the writer lock on the engine’s own terms.
Fields§
§to: Option<LayoutKind>Arrangement to move into — LayoutKind::Nested when absent, as in TS.
from_metadata_file: Option<String>Name the metadata document has now, DEFAULT_METADATA_FILE when absent — the metadata
catalog in format 2, the manifest in format 1.
from_manifest: Option<String>Deprecated alias of from_metadata_file, taking the same value.
metadata_file: Option<String>Name to give the metadata document as part of the move. Unchanged when absent.
manifest_file: Option<String>Deprecated alias of metadata_file, taking the same value.
dry_run: boolReport the moves without touching the disk. A dry run takes no writer lock: it changes nothing, so refusing it because somebody else is writing would only hide the plan.
lock: LockModeHow the writer lock is taken for the length of the move. LockMode::Skip is as dangerous
here as it is in OpenOptions, and for the same reason: the lock is the only thing keeping
this move and another process’s writes off the same files.