Concept: Tamper-proofing

Abstract

It is imperative that a class retain a perfect account of what build steps were taken against a database. So historical versions of a database class must be tamper-resistant.

Body

A class of databases must be tamper-resistant in that it must defend itself against having documentation of previous versions changed once they have been committed to a database.

DataClass defends your class from inadvertent chances in two ways:

When a database class compiled by DataClass is asked to upgrade a database, the first thing it does is inspect that database to see which upgrade steps were made in the past. If there is even the slightest deviation from the expected course of growth, the database class will abort the attempted upgrade without doing anything at all.

DataClass also allows you to prevent editing an historical version without waiting to use it on a production database. This can be accomplished by asserting the hash-code of a version, triggering a compiler error when that version is changed. You can also use the fact that database classes are partial to store each version in its own file, allowing you to further limit changes to those files using source control.

This is an essential part of autonomation but it is not, in and of itself, sufficient. Another important concept is the arrangement of databases into versions.

Related Use Cases

Related Concepts

Other Actions

documentation | all examples | use cases | concepts | keywords