Should not have to do manual fixup after script failure

[GoogleCodeExporter]

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]

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]

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

• Added labels: Component-Docs

[GoogleCodeExporter]

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

• Changed state: Started

[GoogleCodeExporter]

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

• Added labels: Milestone-Release3.0M1
• Removed labels: Milestone-Release3.0

[GoogleCodeExporter]

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:

• fix_it.patch

[GoogleCodeExporter]

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]

Documentation written.

g

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

• Changed state: Done