search

sudr / dbdeploy

Automatically exported from code.google.com/p/dbdeploy
0 stars 0 forks source link

Database consistency flag #4

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
DBDeploy should output a script that records whether the database schema is
currently in a consistent state. At the start of the update it should set
the flag to false (and commit the txn). At the end of the update it should
set the flag to true.

If the update fails, the failure can be automatically detected.

E.g. an application that uses the database can check whether it has been
started against a consistent schema, and fail immediately if it has not.

(We currently check for acceptable schema version, but cannot tell
automatically if an upgrade has failed).

Original issue reported on code.google.com by gtack...@googlemail.com on 18 Dec 2008 at 9:44

GoogleCodeExporter commented 9 years ago 
[deleted comment]
GoogleCodeExporter commented 9 years ago 
Raised to bring forward sf tracker issue
https://sourceforge.net/tracker/index.php?func=detail&aid=2433945&group_id=17009
2&atid=852965

Original comment by gtack...@googlemail.com on 18 Dec 2008 at 9:46

GoogleCodeExporter commented 9 years ago

Original comment by gtack...@googlemail.com on 5 Jan 2009 at 9:29

GoogleCodeExporter commented 9 years ago

Original comment by gtack...@googlemail.com on 5 Jan 2009 at 9:29

GoogleCodeExporter commented 9 years ago 
Thinking about this, I wonder whether this is actually a symptom of issue #12.  
With
transactional DML, and only one piece of DDL per script, the database should 
never
get into a "broken state".

Original comment by gtack...@googlemail.com on 29 Mar 2009 at 11:46

GoogleCodeExporter commented 9 years ago 
Agree with comment 5: correct use of transactionality in change scripts should 
mean 
that the database never gets into an inconsistent state.  

This was just a symptom of issue 12.

Original comment by gtack...@googlemail.com on 14 Sep 2009 at 5:49