schambers/fluentmigrator — pull request #505 by fluffynuts (2014-06-24 19:35:53+00:00)
Title: Firebird migration bugfixes with tests

Please consider the following patches for a pull request. The issues have arisen out of using FluentMigrator in a production environment. Currently, I work around the issues by creating a few facade classes (probably totalling about 100 lines) and overriding the relevant methods with code largely copied out of the original source base, where the actual fix patches are only a few lines.

The fixes all appear to be specific to firebird and the constraining tests have been written with an embedded firebird database created on-the-fly specifically for each test. This explains the large size of the pull request, but it does mean that the tests are well self-contained and don't need a running Firebird server to be run. I hope this is acceptable.

The fixes are for the following issues:
1) when renaming a table which contains data, the insert statement generator which is used to copy data from the original table to the new one is not instructed as to the target table name and schema and consequently the generation of the relevant sql statement fails. The implemented solution is to copy the table Name and SchemaName from the tableDef to the InsertDataExpression
2) when renaming a table which contains data where some fields are null, the migration fails because the GenericQuoter doesn't handle the DbNULL value like it handles the "real" null value. The implemented solution is to handle both the same.
3) when renaming a table which contains a binary/blob field, the subtype of the field is not copied to the new field. This results in fields that were BLOB with a text subtype (for example) becoming pure binary fields, which may have unintended consequences down the line. The implemented fix is to set up the CustomType for the field to contain the sub_type specifier where appropriate.

On style: I realise, after the fact, that I've defaulted to my regular code style of using the "var" keyword where the rest of the codebase doesn't. Apologies if this is incongruous in the FluentMigrator codebase. If you would prefer that I add another patch which converts all "var" usages to their specific types, please let me know -- I don't mind going back and fixing this (or any other incongruous style issue which you may pick up) such that the patch "fits better" with the official FluentMigrator codebase.

I reiterate that I'd really appreciate if this pull request could be reviewed as soon as possible as it would mean that I could clean up a lot of my production code. In addition, the field sub_type fix is not implemented at my side (indeed, I'm not sure, offhand, if doing so is even feasible -- but I'd really like it to be fixed).

Thanks for your consideration.