Rails 4.1.0 beta1 released
41–50 of 61 posts
Re: Rails 4.1.0 beta1 released
#42Always great to see new rails releases. The message signing looks pretty useful. I'm curious when people would use `Module#concerning` though?
Re: Rails 4.1.0 beta1 released
#43Earlier quoted context omitted.
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 m…
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.
(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)
Re: Rails 4.1.0 beta1 released
#44Earlier quoted context omitted.
No everyone likes that approach, some people prefers to save tokens in yaml files (see on github, you will find a dozen o plugins that do same thing)
Just because you can, and others do, doesn't necessarily make it a good idea. By writing & encouraging developers to use the new `secrets` API, we expose them to a bad practise. Not only that, but other solutions exist (like using `Rails.application.config`). I'm not against configuration files per-say, I'm against secrets as persisted values in a codebase. Doing this is bad: https://github.com/search?l=ruby&q=cookie…
Re: Rails 4.1.0 beta1 released
#45Anyone know a gem which will provide the secrets behaviour without waiting for this release?
Re: Rails 4.1.0 beta1 released
#46Wow. These are STELLAR improvements! Check out the release notes here: https://github.com/rails/rails/blob/master/guides/source/4_1... So excited about all of it. Native enum is a blessing. Took me a while to figure it out but here is the required line for your Gemfile: gem 'rails', '4.0.1.beta1' # This works too, but isn't required (thanks to cantoniodasilva's comment below) # gem 'rails', github: 'rails/rails', tag…
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 m…
Re: Rails 4.1.0 beta1 released
#47Re: Rails 4.1.0 beta1 released
#48Re: Rails 4.1.0 beta1 released
#49Is there any good tutorial site or course where I can learn more about ROR? I have a pretty solid knowledge about programming(PHP, C, C++, Objective-C) and I am getting really excited about ROR lately.
Re: Rails 4.1.0 beta1 released
#50Wow. These are STELLAR improvements! Check out the release notes here: https://github.com/rails/rails/blob/master/guides/source/4_1... So excited about all of it. Native enum is a blessing. Took me a while to figure it out but here is the required line for your Gemfile: gem 'rails', '4.0.1.beta1' # This works too, but isn't required (thanks to cantoniodasilva's comment below) # gem 'rails', github: 'rails/rails', tag…
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 m…
- 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/3543.1317224437@sss.pgh...