Feature/disable triggers

[markgould]

In some of our legacy databases we have tables with delete triggers that insert into auditing tables. This is causing some issues with using Respawn.

I've wrapped the delete statement with disable/enable trigger and created a unit test for it.

I thought about adding a flag for this, but wasn't sure if that would be necessary. If customization is necessary in future, maybe the adapters could be made public so one could do something like:

checkpoint.Adapter = new SqlServerDbAdapter { DisableTriggers = true }; 

Not sure why it's messing with the spacing in the other tests.

[jbogard]

Is it possible to check a table has triggers instead of adding it to every delete? That triples overall execution time.

[markgould]

I'm trying to figure out the best way to implement this.

One idea is to have the BuildTableCommandText return an additional column indicating if the table has triggers. Currently I have only implemented the delete trigger logic for MSSQL. The BuildTableCommandText for all the other implementations could simply return 0, if that's acceptable. A "HasTriggers" property could be added to the Table class so when BuildDeleteCommandText is called, I can check if the table has triggers before writing the disable/enable statements.

The other option is to try and do a whole bunch of extra SQL in the BuildDeleteCommandText but that would just slow everything down, so I don't see that as a good option.

Thoughts?

[jbogard]

I think that's fine for just MSSQL, I don't know what the trigger behavior is anyway for the other DBs.