Absolutely empty storage.

Dummy template for UStore, use this when you want to forget exact template and make type of store homomorphic.

UStore with hidden template.

Code of migration for UStore.

Invariant: preferably should fit into op size / gas limits (quite obvious). Often this stands for exactly one stage of migration (one Tezos transaction).

Minimal possible piece of migration script.

Different atoms can be arbitrarily reordered and separated across migration stages, but each single atom is treated as a whole.

Splitting migration into atoms is responsibility of migration writer.

Keeps information about migration between UStores with two given templates. Note that it is polymorphic over whole storage types, not their templates, for convenience (so that there is no need to export the template).

Alias for UStoreMigration which accepts UStore templates as type arguments.

A bunch of migration atoms produced by migration writer.

Wrapper over UStore which is currently being migrated.

In type-level arguments it keeps

• Old and new UStore templates - mostly for convenience of the implementation.
• Remaining diff which yet should be covered. Here we track migration progress. Once remaining diff is empty, migration is finished.
• Names of fields which have already been touched by migration. Required to make getters safe.

Turn Migration into a whole piece of code for transforming storage.

This is not want you'd want to use for contract deployment because of gas and operation size limits that Tezos applies to transactions.

Modify all code in migration.

Safe way to create migration scripts for UStore.

You have to supply a code which would transform MUStore, coverring required diff step-by-step. All basic instructions work, also use migrate* functions from this module to operate with MUStore.

This method produces a whole migration, it cannot be splitted in batches. In case if your migration is too big to be applied within a single transaction, use mkUStoreBatchedMigration.

Get migration script in case of simple (non-batched) migration.

Way of distributing migration atoms among batches.

This also participates in describing migration plan and should contain information which would clarify to a user why migration is splitted such a way. Objects of type batchInfo stand for information corresponding to a batch and may include e.g. names of taken actions and gas consumption.

Type argument structure stands for container where batches will be put to and is usually a list ('[]').

When writing an instance of this datatype, you should tend to produce as few batches as possible because Tezos transaction execution overhead is quite high; though these batches should still preferably fit into gas limit.

Note that we never fail here because reaching perfect consistency with Tezos gas model is beyond dreams for now, even if our model predicts that some migration atom cannot be fit into gas limit, Tezos node can think differently and accept the migration. If your batching function can make predictions about fitting into gas limit, consider including this information in batchInfo type.

See batching implementations in Lorentz.UStore.Migration.Batching module.

Put each migration atom to a separate batch.

In most cases this is not what you want, but may be useful if e.g. you write your migration manually.

Put the whole migration into one batch.

Compile migration for use in production.

Migration script splitted in batches.

This is an intermediate form of migration content and needed because compiling UStoreMigration is a potentially heavyweight operation, and after compilation is performed you may need to get various information like number of migration steps, migration script, migration plan and other.

Version of mkUStoreMigration which allows splitting migration in batches.

Here you supply a sequence of migration blocks which then are automatically distributed among migration stages.

Get migration scripts, each to be executed in separate Tezos transaction.

Get migration scripts as list.

Get information about each batch.

Number of stages in migration.

Render migration plan.

Manually perform a piece of migration.

Merge several migration scripts. Used in manual migrations.

This function is generally unsafe because resulting migration script can fail to fit into operation size limit.

An action on storage entry.

Describes single migration action.

In most cases it is possible to derive reasonable description for migration atom automatically, this datatype exactly carries this information.

Add description of action, it will be used in rendering migration plan and some batching implementations.

Create migration atom from code.

This is an internal function, should not be used for writing migrations.