The type of a checked database descriptor. Conceptually, this is just a DatabaseSettings with a set of predicates. Use unCheckDatabase to get the regular DatabaseSettings object and collectChecks to access the predicates.

Like IsDatabaseEntity in beam-core, but for entities against which we can generate DatabasePredicates. Conceptually, this is the same as IsDatabaseEntity, but with one extra function to generate DatabasePredicates from the description.

Like DatabaseEntity but for checked databases

Convert a CheckedDatabaseSettings to a regular DatabaseSettings. The return value is suitable for use in any regular beam query or DML statement.

A beam-migrate database schema is defined completely by the set of predicates that apply to it. This function allows you to access this definition for a CheckedDatabaseSettings object.

Purposefully opaque type describing how to modify a table field. Used to parameterize the second argument to modifyCheckedTable. For now, the only way to construct a value is the IsString instance, which allows you to rename the field.

Modify a checked table.

The first argument is a function that takes the original table name as input and produces a new table name.

The second argument gives instructions on how to rename each field in the table. Use checkedTableModification to create a value of this type which does no renaming. Each field in the table supplied here has the type CheckedFieldModification. Most commonly, the programmer will use the OverloadedStrings instance to provide a new name.

Examples

Rename a table, without renaming any of its fields:

modifyCheckedTable (_ -> NewTblNm) checkedTableModification

Modify a table, renaming the field called _field1 in Haskell to FirstName. Note that below, FirstName represents a CheckedFieldModification object.

modifyCheckedTable id (checkedTableModification { _field1 = FirstName })

Produce a table field modification that does nothing

Most commonly supplied as the second argument to modifyCheckedTable when you just want to rename the table, not the fields.

A predicate is a type that describes some condition that the database schema must meet. Beam represents database schemas as the set of all predicates that apply to a database schema. The Hashable and Eq instances allow us to build HashSets of predicates to represent schemas in this way.

A Database predicate is a value of any type which satisfies DatabasePredicate. We often want to store these in lists and sets, so we need a monomorphic container that can store these polymorphic values.

Some predicates make sense in any backend. Others only make sense in one. This denotes the difference.

A name in a schema

Convenience synonym for SomeDatabasePredicate

An optional predicate that depends on the name of a table as well as its fields

A predicate that depends on the name of a domain type

A predicate that depends on the name of a table and one of its fields

Represents a particular step in a migration

A series of MigrationSteps that take a database from the schema in from to the one in to. Use the migrationStep function and the arrow interface to sequence MigrationSteps.

A sequence of potentially reversible schema update commands

Free monadic function for Migrations

A migration command along with metadata on whether the command can lose data

Information on whether a MigrationCommand loses data. You can monoidally combine these to get the potential data loss for a sequence of commands.

Run the migration steps between the given indices, using a custom execution function.

Get the result of a migration, without running any steps

Execute a given migration, provided a command to execute arbitrary syntax. You usually use this with runNoReturn.

Remove the explicit source and destination schemas from a MigrationSteps object

Create a MigrationSteps from the given description and migration function.

Given a command in the forward direction, and an optional one in the reverse direction, construct a Migration that performs the given command. Multiple commands can be sequenced monadically.

Given a migration, get the potential data loss, if it's run top-down

Given functions to render a migration step description and the underlying syntax, create a script for the given MigrationSteps.

Run a MigrationSteps without executing any of the commands against a database.

Collect the names of all steps in hte given MigrationSteps