search

sudr / dbdeploy

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

Should not have to do manual fixup after script failure #12

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago 
In the current published version of dbdeploy if a script fails to apply you
have to manually update the changelog table to run again.

This was a regression between 1.0 and 2.0 caused by the attempt to log
start and end times of script runs. 

Insert to changelog should only be done at the end of the script fragment
within the same transaction.  Therefore, once the issue with a script is
fixed dbdeploy can be successfully rerun without manual fixups.

How it worked in 1.0:

BEGIN TRANSACTION

-- content of change script

INSERT INTO CHANGELOG
COMMIT

How it works in 2.0:

BEGIN TRANSACTION
INSERT INTO CHANGELOG
COMMIT

BEGIN TRANSACTION
-- content of change script
UPDATE CHANGELOG
COMMIT

Behaviour should revert to how it worked in 1.0.

Original issue reported on code.google.com by gtack...@googlemail.com on 8 Mar 2009 at 5:11

GoogleCodeExporter commented 9 years ago 
It is worth noting that this may not be entirely solvable.  DDL is not 
transactional 
for most DBMS's, so it will not get rolled back.  The changelog entry should 
get 
rolled back, but not the table creates, etc.  This will leave the db in an 
unknown 
state.

Original comment by akn...@gmail.com on 11 Mar 2009 at 9:51

GoogleCodeExporter commented 9 years ago 
Agreed.   What we do is follow the convention that you put one DDL statement in 
each
dbdeploy script, so that the normal behaviour just works.  This should be 
mentioned
in the docs as a suggestion.

Original comment by gtack...@googlemail.com on 15 Mar 2009 at 5:37

GoogleCodeExporter commented 9 years ago 
r63 fixes most of this from a code point of view.  Still needs docs updating 
(with
suggestion of using one DDL statement per script) and, since the changelog table
structure has changed, an upgrade guide for those upgrading from 2.0.

Original comment by gtack...@googlemail.com on 17 Mar 2009 at 1:36

GoogleCodeExporter commented 9 years ago

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

GoogleCodeExporter commented 9 years ago 
Hi Graham,

why didn't you go for something like the attached patch (which we did for 
2.21), i.e.
ask for the complete_dt to be not null to assume a script to be applied?
This way you can keep the timings. Is there anything we overlooked?

Cheers,
Felix

Original comment by felix.le...@gmail.com on 3 Apr 2009 at 2:09

Attachments:

GoogleCodeExporter commented 9 years ago 
Hey Felix,

That patch only fixes half the problem: you still end up with a half completed 
entry
in changelog, which dbdeploy will then generate a script to re-insert.  Which 
will fail.

Hence, manual fixup is required.  The model used by dbdeploy 1.X (and now 3.0) 
just
requires to fix the problem and re-run dbdeploy.  A small price to pay for 
losing
script start time IMO.

Cheers
g

Original comment by gtack...@googlemail.com on 12 Apr 2009 at 10:13

GoogleCodeExporter commented 9 years ago 
Documentation written.

g

Original comment by gtack...@googlemail.com on 12 Apr 2009 at 1:01