Sequel.migration do
  up do
    alter_table(:dynflow_execution_plans) do
      if @db.database_type == :mysql
        set_column_type :started_at, 'datetime(3)'
        set_column_type :ended_at, 'datetime(3)'
      end
    end

    alter_table(:dynflow_steps) do
      if @db.database_type == :mysql
        set_column_type :started_at, 'datetime(3)'
        set_column_type :ended_at, 'datetime(3)'
      end
    end

    alter_table(:dynflow_delayed_plans) do
      if @db.database_type == :mysql
        set_column_type :start_at, 'datetime(3)'
        set_column_type :start_before, 'datetime(3)'
      end
    end
  end

  down do
    alter_table(:dynflow_steps) do
      if @db.database_type == :mysql
        set_column_type :started_at, Time
        set_column_type :ended_at, Time
      end
    end

    alter_table(:dynflow_steps) do
      if @db.database_type == :mysql
        set_column_type :started_at, Time
        set_column_type :ended_at, Time
      end
    end

    alter_table(:dynflow_delayed_plans) do
      if @db.database_type == :mysql
        set_column_type :start_at, Time
        set_column_type :start_before, Time
      end
    end
  end
end

Increase datetime precision on Mysql
Increase datetime precision on Mysql

After increasing the datetime precision during time serialization, we
started to see issues with the execution_plan.real_time being negative
number.

The calculation of the real_time value takes serialized value of
execution_plan.started_at and substracts it from Time.now.

I've not been able to reproduce this locally, but it was failing
consistently on mysql in Travis CI.

The theory is that the mysql version in the Travis (Mys1ql 14.14) has
been rounding the started_at value, so that at some occasions the
serialized value of started_at might be higher than the Time.now.utc
call when determining the end time.

Increasing the time precision on the datetime columns in Mysql seemed to
resolve the issue.
