Firebird 2 to Firebird 3 with FluentMigrator does not default to Nullable

[Katharina Utecht]

Hello,

I am currently migrating a C# application with Firebird 2 to Firebird 3. We are using FluentMigrator to execute migration scripts. In those migration scripts we only specified if a column is per default not nullable and everything worked well. Every column with no specified null-behavior is per default nullable. 

When I execute the scripts for Firebird 3 the columns for which no null-behavior is defined are non nullable. That obvioulsy causes a lot of errors, and many of those values can and will be null in our tests and later in production. I have started to alter our scripts to specify nullable for each column, but not only is that a lot of work, I am also wondering if this is by design or if there is a setting to make the default be nullable again. 

I have tried to google this issue with both Firebird and FluentMigrator, but couldn't find any information.

If anyone has ran into this problem and knows a fix for this I would be very grateful.

Kind regards,

Katharina Utecht

[Karol Bieniaszewski]

Hi

 

I suppose showing problematic script (example) will speed up helping you.

As porobably „none” on the group is using FluentMigrator

 

Regards,

Karol Bieniaszewski

--
You received this message because you are subscribed to the Google Groups "firebird-support" group.
To unsubscribe from this group and stop receiving emails from it, send an email to firebird-suppo...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/firebird-support/204b22d0-711e-4800-ac6b-ac6b5219a873n%40googlegroups.com.

 

[Mark Rotteveel]

Columns in Firebird are created by default as nullable, this hasn't
changed (I just checked this against Firebird 3.0.10 to be sure), so
this would suggest this is caused by FluentMigrator.

It might make more sense to ask a question on
https://groups.google.com/g/firebird-net-provider or on a forum (or
similar) for FluentMigrator.

This issue might be relevant for your problem:
https://github.com/fluentmigrator/fluentmigrator/issues/1204

Looking at the code of
https://github.com/fluentmigrator/fluentmigrator/blob/master/src/FluentMigrator.Runner.Core/Generators/Base/ColumnBase.cs
(which is used for Firebird) it seems generating NOT NULL columns is the
default (as ColumnDefinition.isNullable is bool?, and it seems to
default to null). I'm not sure why for Firebird 2.x it would behave any
different. Did you maybe also change the version of FluentMigrator?

Mark
--
Mark Rotteveel

[Katharina Utecht]

Hello Karol,

Thanks for your reply. 

One example would be: 

public class Migration1 : FluentMigrator.Migration

{
    public override void Up()
    {
            Create.Table("TABLE_EXAMPLE")
                .WithColumn("ID").AsString(32).NotNullable().PrimaryKey()
                .WithColumn("NAME").AsString(255)
                .WithColumn("SHORTNAME").AsString(128)
                .WithColumn("POS").AsInt32()
                .WithColumn("CODE").AsString(128).NotNullable()
                .WithColumn("EXTERNALID").AsString(36).NotNullable()
                .WithColumn("DELETED").AsInt16().WithDefaultValue(0)
                .WithColumn("CREATED_ON").AsDateTime()
                .WithColumn("UPDATED_ON").AsDateTime();

    }

...

In this example NAME, SHORTNAME and POS are not nullable after the database is created for my FB 3 setup, whereas for FB 2 everything was non nullable. But as Mark Rotteveel already pointed out, the problem might as well be FluentMigrator (even though I haven't found anything in the documentation, it seems I overlooked something).

Regards,

Katharina 

[Katharina Utecht]

Hello Mark,

Thanks for your reply and the links. It seems that I should've tried to search for this problem with other databases as well, as from your links this appears to be a "problem" with postgres as well (and is probably better documented for more popular databases). After reading through those links I guess the problem lies with FluentMigrator so I can close this topic here and try to find a solution with FluentMigrator-settings. But it really helped to get some insight here. 

Regards,

Katharina