Options
All
  • Public
  • Public/Protected
  • All
Menu

A constraint asserts an invariant for data in a clone. When making transactions against the clone, the constraint is 'checked', and violating transactions fail.

Constraints are also 'applied' for incoming updates from other clones. This is because a constraint may be violated as a result of data changes in either clone. In this case, the constraint must resolve the violation by application of some rule.

🚧 Data constraints are currently an experimental feature. Please contact us to discuss constraints required for your use-case.

In this clone engine, constraints are checked and applied for updates prior to their application to the data (the updates are 'interim'). If the constraint requires to know the final state, it must infer it from the given reader and the update.

see

http://m-ld/org/doc/#concurrency

Hierarchy

  • MeldConstraint

Index

Methods

Methods

apply

  • Applies the constraint to an update being applied to the data. If the update would cause a violation, this method must mutate the given update using its assert method, to resolve the violation.

    Parameters

    • state: MeldReadState

      a read-only view of data from the clone prior to the update

    • update: InterimUpdate

      the interim update, prior to application to the data

    Returns Promise<unknown>

    a rejection only if the constraint application fails

check

  • Check the given update does not violate this constraint.

    Parameters

    • state: MeldReadState

      a read-only view of data from the clone prior to the update

    • update: InterimUpdate

      the interim update, prior to application to the data

    Returns Promise<unknown>

    a rejection if the constraint is violated (or fails)

Legend

  • Property
  • Method

Generated using TypeDoc. Delivered by Vercel. @m-ld/m-ld - v0.5.0 Source code licensed MIT. Privacy policy