The Firebird processor had a bug which reverted successfull migrations when dispose on the processor is called at the end of a migration. This patch clears the stack of the changes after commit, to prevent the execution of them at the rollback step (on dispose).
Additionally the SqlSchemaDumper has been improved to have a more correctly DbType mapping. But I don't know how I should map the remaining types.
Finally a bug in SqlSchemaDumper has been fixed which selected the wrong column at the foreignkey extraction part.
Fixed Firebird Processor always referting migration at calling dispose
Fixed bug in SqlServerSchemaDumper at extracting foreignkeys
Fixed wrong DbType mapping in SqlServerSchemaDumper
oh, I also changed the IndexExists check for Firebird. rdb$unique_flag can be NULL or 0, after a backup&restore.
Changed Firebird type mapping to reflect Firebird better
and make it more compatible with SqlServer migration code
I choosed most mappings from http://www.firebirdsql.org/manual/migration-mssql-data-types.html
Forget to change to change the UnitTests for Firebird related to the
Retain column ordering on SQL Server Dump
This is a mix of different things so maybe it would have been better as two pull requests. Changes to the SqlServerDumper are easy to merge in as it is a contrib project.
Changes to Firebird are a little bit more difficult. Are any of these changes to the mappings breaking changes for current users? cc @concept-hf
Thanks for taking the time to make these small fixes and improve the quality of FluentMigrator.
Ok, I'll try to split this up, into two different Pull Request.
Sadly the changes to Firebird would affect current users. But because the current mapping is different between all the different generators I don't know how to fix that without breaking changes.
.AsAnsiString() maps to VARCHAR(255)
On Firebird this mapping without my change is
BLOB SUB_TYPE TEXT
BLOB SUB_TYPE TEXT
and the other way around:
.AsAnsiString(int.MaxValue) would be VARCHAR(MAX) on SQLServer
and Firebird wouldn't even map that and throws an error.
So I have to use to different statements to have a correct mapping (which would miss the sense)
So the change tries to make it more compatible to sql server. sadly other generators (PostgreSQL when I remember correctly) has the same problem.
Don't worry about splitting it up. I can cherry pick if needs be. Next time though!
It is very hard to know how many people are using the Firebird functionality. And it is pretty new, so maybe we should introduce breaking changes. I'll test it out by creating a schema in Firebird with the current implementation and then switch to your implementation and see what breaks.
I believe there is also a third case C: I which you want to support multiple databases at the same time. At least my company has this case. I'm personaly very tired at writing the same statements all over again and only have to change VARCHAR(MAX) to BLOB SUB_TYPE TEXT and vice versa.
Also this is very errorprone, TIMESTAMP in SQLServer is totaly different form TIMESTAMP in Firebird.
So (at least for me) would it be greate to have only a single migration step, which works out of the box on multiple database engines.
If I want to to a more specific thing I still can use the IfDatabase("abc") thing. But I believe most of the time could be done with the default values, at least if the are correct.
I personaly also don't want to let it behave like sql server, because in my opinion the mapping in sql server is not the most intuitive one. I just want to make it more compatible to each other with the least breaking changes for users. And because there are more sql server users than firebird ones, I made the change to the firebird generator.
Firebid is still rolling back transaction, is there any chance this issue to be fixed?
@hmihail You can use my fork if you want https://github.com/woehrl01/fluentmigrator/tree/firebird I use this in production since a year now
it has additional bug fixes to this pull request for firebird
@woehrl01 Thanks! It works, but only if all column names and table names are uppercase. Is that supposed to only work this way?
Are you shure you've used the firebird branch? normaly it should work. I had a similar issue. But I believe I've already fixed that months ago. (woehrl01@0f74102)
I consider this pull as closed, but i am eager to see any clean pr's coming ;)