Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

#802: DB2 did not drop triggers on clean #803

Merged
merged 2 commits into from Oct 14, 2014

Conversation

@pauxus
Copy link
Contributor

@pauxus pauxus commented Jul 16, 2014

Trivial implementation.

* @throws SQLException when the statements could not be generated.
*/
private List<String> generateDropStatementsForTriggers(String schema) throws SQLException {
String dropTrigGenQuery = "select rtrim(TRIGNAME) from SYSCAT.TRIGGERS where TRIGSCHEMA = '" + schema + "'";

This comment has been minimized.

@nycjay

nycjay Jul 16, 2014

Triggers can have dependencies on other triggers (and other db objects). I have not had a chance to test this out yet, but you may want to also join to SYSCAT.TRIGDEP, so the DROP TRIGGER statements are generated in a specific order, when dependencies exists between two or more of them.

This comment has been minimized.

@pauxus

pauxus Jul 16, 2014
Author Contributor

Yes, that could be a problem. However, this could be the case for the other drops as well. As a radical thought: Why not use SYSPROC.ADMIN_DROP_SCHEMA against an random temporary errortable? This would solve all of our dependency problems quite neatly?

This comment has been minimized.

@pauxus

pauxus Jul 16, 2014
Author Contributor

Just a quick afterthought: Dropping an object that a trigger depends on does not result in an error, it simply marks the trigger inoperative. This is also the case for triggers depending on other triggers. So we should be safe to drop them in any order.

This comment has been minimized.

@nycjay

nycjay Jul 16, 2014

I don't use Flyway's clean() functionality, so I suppose leaving inactive triggers/tables/etc around could be ok, depending on your intended use. If you want to run migrate(), clean(), then migrate() again, I could imagine this causing errors if not done in a dependency aware order. Though, I buy that this is a bigger change than what you intended, and may be fine for most use cases. Documentation for the clean() method may want to address the possible limitation.

In regards to using the ADMIN_DROP_SCHEMA command, I have found that to be quite delicate - Once you get a failure, you seem to have to manually clean out errorschema.errortable before you can run it again. That may no longer be an issue with a more modern version of DB2 however.

This comment has been minimized.

@pauxus

pauxus Jul 17, 2014
Author Contributor

In a former project, I worked around the problems with ADMIN_DROP_SCHEMA by explicilty using not ERRORTABLE as target but a temporary table with a generated name. This should work well with flyway, when the name generation is good enough (fw_ should be sufficient, since no two instances of flyway can operate on the same schema at the same time anyway). To be on the safe side, with could check for the existance of the table beforehand and drop it.

I think I will give it a try and create another pull request, if everything works as intended.

For now, a custom version using my pull request at least solves my specific problems (i.e. migrate-clean-migrate works again).

@axelfontaine
Copy link
Contributor

@axelfontaine axelfontaine commented Aug 3, 2014

Thanks for the pull request. Could you also add a test case?

Cheers
Axel

@pauxus
Copy link
Contributor Author

@pauxus pauxus commented Aug 4, 2014

Integration test added.

@axelfontaine
Copy link
Contributor

@axelfontaine axelfontaine commented Aug 5, 2014

Hmmm the triggers you reference in the test are already dropped as part of the drop table. Could you add a test for a case where the drop table is not enough to eliminate the trigger (the case this PR attempts to address I assume)?

@pauxus
Copy link
Contributor Author

@pauxus pauxus commented Aug 5, 2014

They are not, actually, at least not with DB2 10.1. When removing the drop trigger entries from Db2Schema, the new test fails. Which is in accordance to DB2 doc:

"All triggers dependent on the dropped table are marked inoperative."

see: http://www-01.ibm.com/support/knowledgecenter/SSEPGG_9.7.0/com.ibm.db2.luw.admin.dbobj.doc/doc/t0005370.html

@pauxus
Copy link
Contributor Author

@pauxus pauxus commented Sep 9, 2014

Any Progress here?

axelfontaine added a commit that referenced this pull request Oct 14, 2014
#802: DB2 did not drop triggers on clean
@axelfontaine axelfontaine merged commit 3e0f994 into flyway:master Oct 14, 2014
1 check passed
1 check passed
continuous-integration/travis-ci The Travis CI build passed
Details
@pauxus pauxus deleted the pauxus:db2-clean-triggers branch Oct 15, 2014
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked issues

Successfully merging this pull request may close these issues.

None yet

3 participants
You can’t perform that action at this time.