import { Configuration } from '@spinajs/configuration-common';
import { AsyncService, ClassInfo, Container, Class } from '@spinajs/di';
import { Log } from '@spinajs/log-common';
import { OrmMigration } from './interfaces.js';
import { ModelBase } from './model.js';
import { OrmDriver } from './driver.js';
import { MigrationRunner } from './migration-runner.js';
/**
 * What `DI.resolve(Orm, [ ... ])` hands the Orm at construction - the same way a driver is
 * handed its `IDriverOptions`. Not configuration: nothing here comes from a config file, because
 * the one thing it controls has to be a property of THIS PROCESS rather than of the deployment.
 */
export interface IOrmOptions {
    /**
     * Run the boot migration pass - `Migration.up(undefined, { force: false })` and the `data()`
     * phase that seeds whatever it applied? Defaults to true, and an ordinary application never
     * passes it: leaving it out is what keeps `db.Connections[n].Migration.OnStartup` meaning what
     * it says.
     *
     * `false` is for a process whose job is to operate ON the migrations - `@spinajs/orm-cli`
     * passes it. Such a process needs everything else resolve() does ( connections, models,
     * converters, `orm.Migration` ) but must not have the schema move underneath it as a side
     * effect of booting: a boot pass that meets a FAILED row takes down even the command invoked
     * to clear that row, and a boot pass that succeeds turns `migrate-status` from a report into a
     * migration.
     *
     * It is deliberately not a `force` variation. `force` chooses whether the `OnStartup` gate is
     * honoured, and both of its values RUN migrations - `force: false` runs every connection whose
     * gate is on, which is exactly the set a migration tool must not touch on its way in.
     */
    MigrateOnStartup?: boolean;
}
export declare class Orm extends AsyncService {
    protected Options: IOrmOptions;
    Models: Array<ClassInfo<ModelBase>>;
    Migrations: Array<ClassInfo<OrmMigration>>;
    Connections: Map<string, OrmDriver>;
    /**
     * Everything migration-related: `up`, `down`, `status`, `resolve`. Assigned in `resolve()`,
     * once the connections it dispatches to exist - so it is only usable on a resolved Orm.
     */
    Migration: MigrationRunner;
    Container: Container;
    protected Log: Log;
    protected Configuration: Configuration;
    /**
     * `DI.resolve(Orm)` leaves this empty, which is every application: the defaults are the
     * documented behaviour and nothing has to opt into them.
     */
    constructor(Options?: IOrmOptions);
    /**
     * This function is exposed mainly for unit testing purposes. It reloads table information for models
     * ORM always try to load table at resolve time
     */
    reloadTableInfo(): Promise<void>;
    resolve(): Promise<void>;
    /**
     * Runs the `data()` hook of every migration that was just applied - the seeding pass, which
     * happens after models and relations are wired because that is what it is allowed to use.
     *
     * Every hook runs even when an earlier one throws, and the failures are reported together.
     * Stopping at the first one leaves the migrations after it unseeded while their schema is
     * already applied and recorded, so a rerun will not retry them: their tracking rows say
     * "applied", and nothing would ever mention the seeds that never ran.
     *
     * KNOWN LOSS, and it is the same shape one level up: `executed` is what THIS run applied, and
     * this phase runs after the whole run. A run in which M1 applies and M2 throws never reaches
     * here at all - and M1's schema is already recorded, so the next boot does not find it pending,
     * it never enters `executed`, and `M1.data()` never runs on any boot. Nothing reports it: the
     * migration is applied and `status()` is clean.
     *
     * Not fixed here, because the tracking table has no notion of "applied but unseeded" and
     * inventing one would make the seed phase a second, weaker migration state machine - `data()`
     * has no `down()`, no checksum and no failure row, so a "seeded" column would be a claim
     * nothing could verify or undo. It is documented instead ( packages/orm/docs,
     * 10-schema-and-migrations.md ), where the guidance is the one thing that actually holds:
     * write `data()` so that running it again is harmless.
     */
    protected runDataPhase(executed: OrmMigration[]): Promise<void>;
    protected registerDefaultConverters(): void;
    protected wireRelations(): void;
    /**
     *
     * Register model to ORM programatically so ORM can see it and use it. Sometimes dynamical model discovery is not possible eg.
     * in webpack evnironment. In such case we must tell ORM manually what to load.
     *
     * NOTE: use it in ORM constructor before ORM is resolved & model list used.
     *
     * @param model - model to register
     */
    protected registerModel<T extends ModelBase>(model: Class<T>): void;
    /**
     * Everything every `MigrationSource` found, reduced to the migrations this environment runs.
     *
     * Three passes, in this order and for a reason each:
     *
     * - env resolution happens per ENTRY, before anything is merged, because it is the entry's FILE
     *   that carries the suffix;
     * - dedupe merges entries sharing a class name - the normal case, since a file discovered on
     *   disk is also registered through DI by the import that discovered it, and `src` and `lib`
     *   hold the same class twice;
     * - filtering happens here rather than in `MigrationRunner.plan()` so a migration belonging to
     *   another environment never enters `Orm.Migrations` at all, and is therefore absent from
     *   `up`, `down` AND `status` alike.
     */
    protected discoverMigrations(): Promise<Array<{
        type: Class<OrmMigration>;
        file: string;
    }>>;
    /**
     *
     * Register migration to ORM programatically so ORM can see it and use it. Sometimes dynamical migration discovery is not possible eg.
     * in webpack evnironment. In such case we must tell ORM manually what to load.
     *
     * NOTE: use it in ORM constructor before ORM is resolved & migrate function used.
     *
     * @param model - model to register
     */
    protected registerMigration<T extends OrmMigration>(migration: Class<T>, file?: string): void;
    private createConnections;
    private applyModelMixins;
    dispose(): Promise<void>;
}
//# sourceMappingURL=orm.d.ts.map