We pushed a build to RubyGems.org[1], so you should be able drop the github option now:

    gem 'rails', '4.1.0.beta1'

We upgraded a few apps in our local Ruby meetup group lately[2], and it's worth mentioning that you might need to upgrade the following gems too:

    gem 'rspec', '~> 3.0.0.beta1'
    gem 'rspec-rails', '~> 3.0.0.beta1'
    gem 'capybara', '~> 2.2.0'
    gem 'jquery-rails', github: 'takkanm/jquery-rails', branch:' fix_action_view_require'
    (I'm not 100% sure about the last one, might have been fixed since I last checked)

I'll try to write this up in another blog post tomorrow.

[1]: http://rubygems.org/gems/rails/versions/4.1.0.beta1

[2]: http://www.meetup.com/vancouver-ruby/messages/61805312/

Edit: minor formatting fixes

It's a shame these aren't actual database ENUMs, but rather ints (with the mapping in ruby land): https://github.com/rails/rails/commit/db41eb8a6ea88b854bf5cd...

Even a text column would be preferable IMO ... you wouldn't need to worry about remapping if a value got removed, it's more easily queryable, and it's certainly more legible if you're looking at raw data (say, via psql). Plus you probably won't really save much (any?) space with an (64-bit) int.

Native "enums" (types) in PostgreSQL are a mixed bag. They do have some advantages:

- you can treat them like strings (e.g. `SET status = 'approved'`, but they are a fixed size (four bytes)

- when queried they appear as strings too. Nice for debugging

- if you enter an invalid value (anywhere, not just in Rails) PG will throw a wibbly

But the biggest problem with enum types is if/when you want to add a new value to an enum type, it's annoyingly non-trivial. You can't run `ALTER TYPE ... ADD` because it doesn't work in a transaction. [0]

Instead you need to drop the type, recreate it (with the new value) and then alter all the tables that use this type. If you have a huge DB this can get a bit silly, although you can at least do it all in a transaction.

It is fairly trivial to add support for real Postgres enum types - https://gist.github.com/clarkdave/5936375 - but it's not as elegant as having it properly supported by ActiveRecord.

As other posters have mentioned here, it'd be useful if Rails' enum support used text instead of integers. You could then set up a Check constraint in PG to enforce the correct values and stop invalid data slipping into your database from other sources, whilst keeping the nice sugar in ActiveRecord.

[0] http://www.postgresql.org/message-id/[email protected]...

Considering the sad state of mysql enums with the pitfalls it have, it really isn't a shame.

I totally agree that a text column would have been preferable though.

Shouldn't the mapping to database be backend-dependent anyway? SQLite has more or less no feature, yet ORMs don't feel the need to restrict themselves to what sqlite can do.

(nota: oracle and mssql don't, afaik, have an enum type either)

(and in Postgres, enum is not a type, it's a type constructor. First you have to `CREATE TYPE yourtype AS ENUM ( values... )` then you can use `yourtype` in a table, you can't have a column of type `ENUM ( whatever )` because Postgres enums are disjoint and not structurally equivalent)

I agree with all of your points, but I don't think it's a shame. It's an awesome contribution and will make my work a lot easier on future projects. I'm personally going to try and take a stab at implementing this with strings versus ints though, since I agree you don't really save much by using the int and it's much friendlier for debug and future changes.

You can specify a smaller int size, I used 2-byte ints fairly often. Saves a good amount of space. This also makes it really easy to change the corresponding name of a value/categorization (no migration needed).

You should be able to point the gem to '4.1.0.beta1' too, instead of relying on the git tag.

Good to know, thanks.

Note to the Rails team: might want to add this to your blog post and/or release notes?

Perhaps I am the only person in the world who did not realize this would work. #noob