[Feature request] Raise an error for invalid options on migrations

[Ian Ker-Seymer]

Currently, when creating a migration and the user specifies an invalid option, the migration silently succeeds and does not notifiy the user that the option is meaningless.

Given this migration for postgres:

```ruby

class CreatePost < ActiveRecord::Migration[5.0]

  def change

    create_table :posts do |t|

      t.text :description, limit: 5000

    end

  end

end

```

When we run this migration, the schema will be created, and everything appears to have succeeded. It will result in something like this:

```ruby

ActiveRecord::Schema.define(version: 20160601201548) do

  create_table "posts", force: :cascade do |t|

    t.text "description", null: false

  end

end

```

The schema is correct and does not impose a `limit: 5000` on the  `description` column. However, I find the developer experience to be confusing as it does not warn that there is no possible limit constraint on a `text` column. This can lead to issues like a developer expecting a limit when there is none.

Proposed solution

Raise an error where there are invalid options given in migrations. Instead of silently succeeding on `rake db:migrate`, throw a `ActiveRecord::InvalidDatabaseConstaint` or something similar. This way, the user is made aware of mistakes they may have made. 

I am happy to work on this issue if there is consensus that this is a positive change. Please post your thoughts here! Thanks :smile: 

[Jason Fleetwood-Boldt]

+1 on guardrails for Rails (pun intended)

Silent unseen errors are always the worst kind.

-jason

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-co...@googlegroups.com.
To post to this group, send email to rubyonra...@googlegroups.com.
Visit this group at https://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.

[Rafael Mendonça França]

Like I said in the original issue https://github.com/rails/rails/issues/25330#issuecomment-224787746

This proposed solution makes impossible to different adapters introduce different options to the migration helpers without monkey patching rails. In you specific case, a database like Oracle could accept a limit option in the text column and that would raise an error.

[Ian Ker-Seymer]

Rafael, why would it not be possible? Is this an architectural issue with the current rails code?

[Rafael Mendonça França]

It is an limitation of the implementation.

All database adapters share the same migrations helpers. If the SQLite3 adapter doesn't not accept the `limit` option to a string column and we raise an error when the users pass it the PostgreSQL adapter will also raise an error even that it is supported for that database.

Today it is also possible to write plugins to the migration helper easily without having to monkey patch them, changing to raise errors when the option is unknown will require these plugins to monkey patch them.

On Mon, Jun 13, 2016 at 1:19 PM Ian Ker-Seymer <i.ker...@gmail.com> wrote:

Rafael, why would it not be possible? Is this an architectural issue with the current rails code?