selda-0.5.1.0: Multi-backend, high-level EDSL for interacting with SQL databases.

Safe HaskellNone
LanguageHaskell2010

Database.Selda.Migrations

Description

Functionality for upgrading a table from one schema to another.

Synopsis

Documentation

data Migration backend where Source #

Wrapper for user with migrateAll, enabling multiple migrations to be packed into the same list:

migrateAll
  [ Migration m1_from m1_to m1_upgrade
  , Migration m2_from m2_to m2_upgrade
  , ...
  ]

Constructors

Migration :: (Relational a, Relational b) => Table a -> Table b -> (Row backend a -> Query backend (Row backend b)) -> Migration backend 

migrate Source #

Arguments

:: (MonadSelda m, MonadMask m, Relational a, Relational b) 
=> Table a

Table to migrate from.

-> Table b

Table to migrate to.

-> (Row (Backend m) a -> Row (Backend m) b)

Mapping from old to new table.

-> m () 

Migrate the first table into the second, using the given function to migrate all records to the new schema. Both table schemas are validated before starting the migration, and the source table is validated against what's currently in the database.

The migration is performed as a transaction, ensuring that either the entire migration passes, or none of it does.

migrateM :: (MonadSelda m, MonadMask m, Relational a, Relational b) => Table a -> Table b -> (Row (Backend m) a -> Query (Backend m) (Row (Backend m) b)) -> m () Source #

Like migrate, but allows the column upgrade to access the entire database.

migrateAll Source #

Arguments

:: (MonadSelda m, MonadMask m) 
=> Bool

Enforce foreign keys during migration?

-> MigrationStep (Backend m)

Migration step to perform.

-> m () 

Perform all given migrations as a single transaction.

autoMigrate Source #

Arguments

:: (MonadSelda m, MonadMask m) 
=> Bool

Enforce foreign keys during migration?

-> [MigrationStep (Backend m)]

Migration steps to perform.

-> m () 

Given a list of migration steps in ascending chronological order, finds the latest migration step starting state that matches the current database, and performs all migrations from that point until the end of the list. The whole operation is performed as a single transaction.

If no matching starting state is found, a ValidationError is thrown. If the database is already in the state specified by the end state of the final step, no migration is performed.

Note that when looking for a matching starting state, index methods for indexed columns are not taken into account. Two columns c1 and c2 are considered to be identical if c1 is indexed with index method foo and c2 is indexed with index method bar.