pg-flyway
Version:
Migration tool for PostgreSQL database, NodeJS version of Java migration tool - flyway (not wrapper for https://flywaydb.org/documentation/commandline)
109 lines (108 loc) • 4.36 kB
TypeScript
export declare const CALLBACK_KEYS: (keyof Migration['callback'])[];
export type MgrationFileMetadata = {
filepath: string;
sqlMigrationSuffix: string;
location: string;
};
export declare class Migration {
filepath?: string | undefined;
sqlMigrationSeparator?: string | undefined;
sqlMigrationStatementSeparator?: string | undefined;
sqlMigrationSuffix?: string | undefined;
location?: string | undefined;
name?: string;
filechecksum?: number;
filedir?: string;
filename?: string;
script?: string;
version?: number;
/**
* https://documentation.red-gate.com/fd/migrations-184127470.html
*
* Versioned migrations have a version, a description and a checksum.
* The version must be unique. The description is purely informative for you to be able to remember what each migration does.
* The checksum is there to detect accidental changes.
* Versioned migrations are the most common type of migration. They are applied in order exactly once.
*/
versioned: boolean;
versionedVersion?: number;
undo: boolean;
undoVersion?: number;
/**
* https://documentation.red-gate.com/fd/migrations-184127470.html
*
* Repeatable migrations have a description and a checksum, but no version.
* Instead of being run just once, they are (re-)applied every time their checksum changes.
* Within a single migration run, repeatable migrations are always applied last, after all pending versioned migrations have been executed.
* Repeatable migrations are applied in the alphanumeric order of their description.
*/
repeatable: boolean;
/**
* https://documentation.red-gate.com/fd/callback-concept-184127466.html
*
* While migrations are sufficient for most needs, there are certain situations that require you to execute the same action over and over again.
* This could be recompiling procedures, updating materialized views and many other types of housekeeping.
* For this reason, Flyway offers you the possibility to hook into its lifecycle by using Callbacks.
* In order to use these callbacks, name a script after the callback name (ie. afterMigrate.sql) and
* drop it alongside your other scripts in your migrations folder.
* Flyway will then invoke it when the execution event criteria listed below is met.
*/
callback: {
/**
* Before Migrate runs
*/
beforeMigrate?: boolean;
/**
* Before all repeatable migrations during Migrate
*/
beforeRepeatables?: boolean;
/**
* Before every single migration during Migrate
*/
beforeEachMigrate?: boolean;
/**
* Before every single statement of a migration during Migrate
*/
beforeEachMigrateStatement?: boolean;
/**
* After every single successful statement of a migration during Migrate
*/
afterEachMigrateStatement?: boolean;
/**
* After every single failed statement of a migration during Migrate
*/
afterEachMigrateStatementError?: boolean;
/**
* After every single successful migration during Migrate
*/
afterEachMigrate?: boolean;
/**
* After every single failed migration during Migrate
*/
afterEachMigrateError?: boolean;
/**
* After successful Migrate runs
*/
afterMigrate?: boolean;
/**
* After successful Migrate runs where at least one migration has been applied
*/
afterMigrateApplied?: boolean;
/**
* After all versioned migrations during Migrate
*/
afterVersioned?: boolean;
/**
* After failed Migrate runs
*/
afterMigrateError?: boolean;
};
statements: string[];
statementLines: number[];
static fromStatements({ statements }: {
statements: string[];
}): Migration;
constructor(filepath?: string | undefined, sqlMigrationSeparator?: string | undefined, sqlMigrationStatementSeparator?: string | undefined, sqlMigrationSuffix?: string | undefined, location?: string | undefined);
fill(fileContent: string): Promise<this>;
stripBom(string: string): string;
}