Versioning

BioDM allows to decorate some tables with a Versioned mixin class populating an extra version field in the primary_key.

A versioned entity gets an extra /release endpoint allowing to bump the version number, which is not editable via classical updates like all primary key fields.

Other fields remain editable, to make versioned entities read-only you may use another mixin: StrictVersioned which shall raise errors upon updating associated entities.

Deep clones

Since an entity is more than a single table row but an actual object with relationships releasing tries to accomodate passing on the object tree.

Hence, some tied objects are recursively deep cloned according to the following policy in respect of the relationship directions with the object that gets released (or its deep cloned children):

• MANYTOONE

Not cloned, released item will be added to the list of children

• Exception: permissions

Technically permissions and attached list of allowed groups are MANYTOONE relationships, however those do get cloned to allow for independent evolution of relationships accross versions.

• MANYTOMANY

Not cloned, released item will adop those same children

• ONETOMANY

Cloned, released item will adopt those new children in place of former ones

Primary keys

In case a child gets deep cloned, it needs some new primary keys.

BioDM will erase all parts of the key that have default values except the version and let SQLAlchemy session flush do the rest of the work.

That works well in canonical cases such as leading autoincrement id, but be aware of that policy as it may not cover all use cases and possibly lead to errors if not careful during table building.

Alternatively, to decide of a new primary key generation or relationship cloning behaviour have a look at the next section.

Custom behaviour

In case default behaviour is not satisfying your use case, you may override Base.clone method for any of your tables.