import { OrmDriver } from './driver.js';
import { IIdentityMap, IModelDescriptor, ISaveOptions, ISaveResult } from './interfaces.js';
import type { ModelBase } from './model.js';
/**
 * The `save()` entry point: one transaction, one identity map, one ordered plan.
 */
export declare class UnitOfWork {
    /**
     * Persists everything reachable from `root` atomically.
     *
     * @param root - the model `save()` was called on
     * @param options - `reload` to diff against current database state; `chunk` to bound the row
     *        count of the statements that ARE batched — junction inserts and the key lists of
     *        orphan statements. It does not apply to model inserts: those run one statement per
     *        row so each generated key can be read back exactly. See {@link ISaveOptions}.
     */
    static save(root: ModelBase, options?: ISaveOptions): Promise<ISaveResult>;
    /**
     * The identity map for this save. Reused across saves inside one transaction so a row
     * touched by two of them is still one object; created fresh otherwise. Nothing survives
     * the transaction ( decision D7 ).
     */
    protected static identityMapFor(driver: OrmDriver): IIdentityMap;
    /**
     * A graph spanning two connections cannot be persisted atomically — the transaction only
     * covers one of them. Fail loudly rather than commit half of it.
     */
    protected static assertSingleConnection(models: ModelBase[], root: IModelDescriptor): void;
    /**
     * Re-reads every already-persisted model's row and rebases it on the database's current
     * values, batched one SELECT per model class.
     *
     * This is a three-way merge between the hydration baseline, the model, and the row as it
     * stands now. A column the caller edited keeps the caller's value and is rebased so it is
     * written; a column the caller did not touch is reset to the current database value on the
     * model *and* in the baseline, so it drops out of the diff and is not written at all.
     *
     * Moving only the baseline would do the exact opposite of the intent: the model would still
     * hold the stale hydration value, the diff would report `current -> stale`, and the UPDATE
     * would clobber whatever another process wrote. The model has to move too.
     *
     * This is a last-write-wins rebase, not conflict detection: two callers editing the same
     * column still race, and neither is told.
     */
    protected static reloadSnapshots(models: ModelBase[]): Promise<void>;
    /**
     * Re-records every populated relation's member keys after a successful save, so a second
     * `save()` on the same graph sees no membership change and emits nothing.
     */
    protected static resnapshotRelations(models: ModelBase[]): void;
}
//# sourceMappingURL=unit-of-work.d.ts.map