Explicit revision dependencies

[ghost]

The dependencies should not depend on the time stamp. Instead, they form a lineage structure that should be explicit. In general, the migrations my form a tree, such that one can accommodate a .../test and a ../production line of migrations in parallel.

Much like branches in mercurial/git.

[sstalin]

ok we ca discuss this more in details

[ghost]

As confirmed during the call, a revision system will borrow a lot from a standard software revision scheme, such as in GIT. This means the revisions are 'centrally' administered ( your migration directory), but exhibit the following information. The revisions are explicitly organized in a DAG, directed cyclic graph.

• create migration -> top T
• commit a revision -> C1 ->top T
• commit a revision -> C2-> C1->top After the upgrade the current revision is C2.

It should be noted that the actual state of the target system contains much more than the definitions. The database is filled with data and downgrading is not necessarily possible. For example, a revision not only changes the structure but could also change the database content based on random/temporal expressions.

For example, UPDATE personel SET sal = s * 1.1 WHERE hired < now() - 1 year;

This means to make sense, one should already keep around the exact SQL, where all information is retained. In this case the value of now.

Another example, UPDATE personnel SET hired = now() - 1 month where username like 'john'

These examples show that revision management is tightly coupled with keeping logs around, e.g. the lazy logical log. That way we can at lease roll forward again from scratch or recognize that the roll forward can start at a known snapshot.