7 ms·

Rails 4.2 released

234 points by chancancode 12y ago

te_chris 12y ago
Congratulations guys. I love working with a framework that is always getting better, looking forward to deploying ActiveJob. GlobalID is great!
amalag 12y ago
Rails 4.2 does NOT work with JRuby. There are pending issues on activerecord-jdbc: https://github.com/jruby/activerecord-jdbc-adapter/issues/599 https://github.com/jruby/activerecord-jdbc-adapter/issues/59...
ma2ge 12y ago
Congrats!! I'd like to upgrade Rails 4.2 from 4.2.0.rc3, thanks!
- emocakes 12y ago
  good for you. I'd like a nice car.
jrochkind1 12y ago
I think ActiveJob is a great thing, a real step forward to have a Rails-endorsed API for this others can hook into on both sides. Awesome. But am I the only one who gets a sort of pit in their stomach every time they hear about a new Rails version? So many things to upgrade, so many dependencies that might break, and then Rails 5 coming in less than 12 months when I get to do it again, I have to admit the Rails treadmill is exhausting me.
- DAddYE 12y ago
  Usually if I have a production project I avoid to step out through major releases. As you have seen they do bug fixes for previous stable releases, which is awesome and IIRC the security one go even deeper to the tree. No one force us to upgrade, but I do love upgrades, usually (if well done like this one) are full of things that may help our coding life and speed performances? Are always well welcome!
- reledi 12y ago
  I get excited about every stable release and try to switch as soon as possible. When you keep up with the incremental updates then the upgrade process isn't too bad IMO.
  - adriand 12y ago
    That's easy when you have just one, or a handful, of production projects to maintain. When you have hundreds it's a vastly different story. But that's where I think https://railslts.com/ https://railslts.com/ comes in.
    - deleted 12y ago
      [deleted]
- username223 12y ago
  > But am I the only one who gets a sort of pit in their stomach every time they hear about a new Rails version? Welcome to modern software. I'm not on the Rails treadmill, but arbitrary breakage every month/quarter/year, possibly enforced by a hard-to-disable automatic update system, seems to be the new normal. Heaven help you if you write or use software that depends on "modern" software.
  - tomcam 12y ago
    Not true at all. web2py is infinitely more capable than rails and has been compatible in all releases since 1.0, over 7 years ago.
    - tomcam 12y ago
      Would like to understand reason for downvotes...
      - rhizome 12y ago
        Were you actually being serious?
      - nazgob 12y ago
        web2py is not comparable to rails.
  - lotyrin 12y ago
    Hard to disable? Most of the dependency tracking tools I'm aware of, spanning from system level to application level, require you to intervene by default, even in the case of security releases and/or even have nice version pinning features. As the maintainer of an internet facing application, it's part of your ongoing responsibility to, for security reasons, continuously integrate upon your dependencies. Nothing's fire and forget, it's not sensible not to stand on the shoulders of all these giants around us, but when we do we have responsibility to integrate their security fixes and not break our apps. Not sure where you draw your line of what"modern" software is when not even system packages and package managment are safe when we have Heartbleeds and ShellShocks, Kernel Vulns et al. Unless you just mean the bros pumping out new NPM modules/Rubygems/etc, half-assing SemVer, disregarding compatibility as a goal, and only releasing fixes (security-related even) for the latest major version that came out several months ago, or abandoning them. Yeah, that's some serious BS and I hope things mature.
- gareim 12y ago
  I just started learning Rails and haven't deployed yet, but the thought of upgrading after deploying a project scares me a lot.
  - patrickdavey 12y ago
    Why does it scare you? It's good to be wary of the upgrade process.. but this is why you have (I hope!) database backups and source control (as a minimum). Then at least you can roll back. Then it's just extras after that, test coverage, staging servers etc. etc. Anyway, upgrading is a fact of life once you're using a framework (unless you want to get hacked) so best to get used to it :) Good luck!
  - diasks2 12y ago
    I've found the best way to make upgrading easier is having good test coverage. I think one of the biggest fears when upgrading is having something break but not knowing that it is now broken. Although tests won't always catch everything they are a great start to ease the upgrade process.
  - cies 12y ago
    To have tests (and particularly integration tests) is a big help; as has already been mentioned. Another thing is to use staged deployments: dont deploy to production-env from you development-env, but to a staging-env (if possible using the same or a copy of the live database). Then have a look with some (possibly non-technical) humans if the app still behaves as expected. While it can be laborious for a large app, it should make a deployment to production a lot less scary. As mentioned by others: upgrading is part of running a web app that depends on popular libs.
- deleted 12y ago
  [deleted]
- whistlerbrk 12y ago
  I don't. I feel like the deprecations and API changes have mostly been quite minor since 4.x. A lot of this is shedding weight from supporting Ruby 1.9 and 1.8.7, so if you've been up to date on that front (gem and code wise) you've been okay. I'm looking forward to 5, but I'd like to see what the feature set is. Namely building real time and concurrent apps in _Ruby_ doesn't feel natural on _Rails_ and I hope it can be.
- douglasfshearer 12y ago
  Rails used as intended can be a real pain to upgrade, I agree. Recently I have been developing applications in the "thin-model, thin-controller, with a service layer and external API wrappers" style, as espoused by Gary Bernhardt [1] and others [2] [3] [4] [5]. I upgraded to the latest Rails this morning on one app, and apart from swapping the Money gem to use the git repository, until they have a new version out with compatible dependency, it went smoothly. All the specs and acceptance tests passing with no alteration required. [1] https://github.com/garybernhardt/sucks-rocks https://github.com/garybernhardt/sucks-rocks [2] http://jamesgolick.com/2010/3/14/crazy-heretical-and-awesome-the-way-i-write-rails-apps.html http://jamesgolick.com/2010/3/14/crazy-heretical-and-awesome... [3] http://objectsonrails.com/ http://objectsonrails.com/ [4] http://solnic.eu/2011/08/01/making-activerecord-models-thin.html http://solnic.eu/2011/08/01/making-activerecord-models-thin.... [5] https://www.youtube.com/watch?v=CGN4RFkhH2M https://www.youtube.com/watch?v=CGN4RFkhH2M
  - rapind 12y ago
    Anyone else thinking "EJB on Rails"?
- mbesto 12y ago
  I'd love for Rails to have some incremental LTS releases. Not that the Rails organization itself has to provide support, but rather the community decides which releases are most suited for LTS support. This would force gem providers (and automated CI's) to test on those releases.
  - alxndr 12y ago
    Have you seen https://railslts.com/ https://railslts.com/ ? > "Rails LTS is a commercially supported fork of Rails 2.3 (and soon Rails 3.2) that continues to receive security patches now that official support has ended."
- websitescenes 12y ago
  Upgrading between from 2.x to 3.x or 3.x to 4.x can tend to be tricky but I have not had many, if any, issues upgrading from 4.x to 4.2. Typically if a functionality is removed or deprecated from the framework, you will find a gem will popup that can be included so your legacy code still functions. I often take this approach since we maintain mountains of Rails apps from 2.x to 4.x. If you are working on a handful of apps or a single app, I think it is worth it to stay as current as possible and update with every new release. Your knowledge of the framework and the quality of the product will increase with every iteration.
- hmans 12y ago
  Unless you need one of the new features on offer, there is no reason why you would need to upgrade right away. It's perfectly okay to give a new Rails release a couple of months to settle, including gems that need to be compatible with it.
TallboyOne 12y ago
I'm just waiting on Delayed Job at this point :)
- reledi 12y ago
  What do you mean? Is DJ supposed to become a Rails built-in library?
  - brandoncordell 12y ago
    No, but Rails has ActiveJob[1] which allows you to use backends interchangeably (see heading 4.1 of the link I posted). [1] http://edgeguides.rubyonrails.org/active_job_basics.html http://edgeguides.rubyonrails.org/active_job_basics.html
- xal 12y ago
  DJ could use a update to be fully Rails 4.2 compatible. I'd love a PR for that and would merge. https://github.com/tobi/delayed_job https://github.com/tobi/delayed_job
  - reledi 12y ago
    The repo you linked to is dead. DJ is in active development at https://github.com/collectiveidea/delayed_job https://github.com/collectiveidea/delayed_job.
- deleted 12y ago
  [deleted]
reledi 12y ago
Seasons greetings Rails team; thanks for the gifts.
MaxGabriel 12y ago
Has anyone had issues upgrading? Alot of our tests that check a value from a the session are failing; haven't been able to figure out why so far.
- cpg 12y ago
  https://github.com/binarylogic/authlogic/issues/432 https://github.com/binarylogic/authlogic/issues/432
sergiotapia 12y ago
The Rails team make so many developers happy worldwide, it's incredible. Thank you from the bottom of my heart for making my job suck less. --- A quick questions regarding Foreign Key support, in the past I would use these concepts normally but does this mean that before Rails did not use Foreign Keys (in the strict rdbms sense)? Does this mean that there are now easy performance gains if you're using their new -real- foreign key support?
- amalag 12y ago
  To your first question, Rails tried to enforce some constraints at the application level, but it was lacking. I worked in a large production system and for extra safeguards their were DB level foreign key constraints. They are kind of a pain to unwind and make changes, but they can save your butt if you accidentally delete something. Second question: You can see this answer: http://stackoverflow.com/questions/507179/does-foreign-key-improve-query-performance http://stackoverflow.com/questions/507179/does-foreign-key-i...
  - ikawe 12y ago
    Read more about the shortcomings of application level reference validations here: http://robots.thoughtbot.com/referential-integrity-with-foreign-keys http://robots.thoughtbot.com/referential-integrity-with-fore... Note: that post talks about using `foreigner` gem which predates having foreign key support in rails core.
- ikawe 12y ago
  Using `belongs_to` or `references` in a migration is simply an alias for an integer column (that conventionally holds the id of another row) without any foreign key constraints. Foreign key constraints aren't about performance - they are about maintaining [referential integrity]. previously... pet.id # => 4 owner.update_attribute(:pet_id, 4) pet.destroy owner.pet # what should this equal? Now this will throw an error. pet.id # => 4 owner.update_attribute(:pet_id, 4) pet.destroy # <= raises Error:trying to destroy a record that is referenced by the owners table. owner.update_attribute(:pet_id, nil) pet.destroy # no problem now. [referential integrity] http://en.wikipedia.org/wiki/Referential_integrity http://en.wikipedia.org/wiki/Referential_integrity
andyl 12y ago
Rails4.2 the day after Postgres9.4. A great combination. Postgres9.4 has JsonB, Json, Hstore and Array fields. Rails4.2 fixes the dirty-tracking for JsonB/Json/Hstore. Thank you developers!
- jrochkind1 12y ago
  > Postgres9.4 has JsonB, Json, Hstore and Array fields. Rails4.2 fixes the dirty-tracking for JsonB/Json/Hstore. Oh, I hadn't caught that, awesome! Can you link to docs and/or commit? I'm wondering if it will do "partial updates" yet -- postgres supports, I think for Json too but definitely for Hstore, a statement that says "just update these keys with these values, leave the other key/values alone". The reason you'd be interested in this is multi-client concurrency, so one client updating some keys doesn't overwrite changes made at about the same time by another client updating only other keys. Lets you use hstore/json in certain circumstances of multi-process concurrency that otherwise you'd have to use normalized separate rows for. When I had tried to look at ActiveRecord on my own to figure out if I could get it to do this, it seemed like it oughta be possible (AR is already tracking the original value for dirty tracking, I think) but I never quite could figure it out, how to hook into the SQL-generation to do it.
deleted 12y ago
[deleted]
gfodor 12y ago
Congrats, and thanks so much for your hard work rails team.
poppup 12y ago
I have been using rails for many years now and I'm sad to say I'm leaving it behind in my current/new project :( I will miss the familiar patterns and want to express my gratitude to the team that makes everything work so seamlessly.
- copperx 12y ago
  Which framework will you be using now?
- nilved 12y ago
  What are you using instead?
ghiculescu 12y ago
I found http://samsaffron.com/archive/2014/12/01/speeding-up-rails-4-2 http://samsaffron.com/archive/2014/12/01/speeding-up-rails-4... (from the post's comments) interesting. It looks like there were initially quite a few performance regressions in the new release. Adequate Record looks great for rails scaffolds, but (at this stage) doesn't look like it will very useful for production apps that probably have more complex queries. For example, it stops working if your query has a `where`. Big thanks to Sam et al for their work in speeding things up.
izietto 12y ago
Finally official foreign keys support \o/

234 points by chancancode 12y ago

Congratulations guys. I love working with a framework that is always getting better, looking forward to deploying ActiveJob. GlobalID is great!

amalag 12y ago

Rails 4.2 does NOT work with JRuby. There are pending issues on activerecord-jdbc: https://github.com/jruby/activerecord-jdbc-adapter/issues/599 https://github.com/jruby/activerecord-jdbc-adapter/issues/59...

ma2ge 12y ago

Congrats!! I'd like to upgrade Rails 4.2 from 4.2.0.rc3, thanks!

emocakes 12y ago
good for you. I'd like a nice car.

jrochkind1 12y ago

I think ActiveJob is a great thing, a real step forward to have a Rails-endorsed API for this others can hook into on both sides. Awesome. But am I the only one who gets a sort of pit in their stomach every time they hear about a new Rails version? So many things to upgrade, so many dependencies that might break, and then Rails 5 coming in less than 12 months when I get to do it again, I have to admit the Rails treadmill is exhausting me.

DAddYE 12y ago
Usually if I have a production project I avoid to step out through major releases. As you have seen they do bug fixes for previous stable releases, which is awesome and IIRC the security one go even deeper to the tree. No one force us to upgrade, but I do love upgrades, usually (if well done like this one) are full of things that may help our coding life and speed performances? Are always well welcome!
reledi 12y ago
I get excited about every stable release and try to switch as soon as possible. When you keep up with the incremental updates then the upgrade process isn't too bad IMO.
- adriand 12y ago
  That's easy when you have just one, or a handful, of production projects to maintain. When you have hundreds it's a vastly different story. But that's where I think https://railslts.com/ https://railslts.com/ comes in.
  - deleted 12y ago
    [deleted]
username223 12y ago
> But am I the only one who gets a sort of pit in their stomach every time they hear about a new Rails version? Welcome to modern software. I'm not on the Rails treadmill, but arbitrary breakage every month/quarter/year, possibly enforced by a hard-to-disable automatic update system, seems to be the new normal. Heaven help you if you write or use software that depends on "modern" software.
- tomcam 12y ago
  Not true at all. web2py is infinitely more capable than rails and has been compatible in all releases since 1.0, over 7 years ago.
  - tomcam 12y ago
    Would like to understand reason for downvotes...
    - rhizome 12y ago
      Were you actually being serious?
    - nazgob 12y ago
      web2py is not comparable to rails.
- lotyrin 12y ago
  Hard to disable? Most of the dependency tracking tools I'm aware of, spanning from system level to application level, require you to intervene by default, even in the case of security releases and/or even have nice version pinning features. As the maintainer of an internet facing application, it's part of your ongoing responsibility to, for security reasons, continuously integrate upon your dependencies. Nothing's fire and forget, it's not sensible not to stand on the shoulders of all these giants around us, but when we do we have responsibility to integrate their security fixes and not break our apps. Not sure where you draw your line of what"modern" software is when not even system packages and package managment are safe when we have Heartbleeds and ShellShocks, Kernel Vulns et al. Unless you just mean the bros pumping out new NPM modules/Rubygems/etc, half-assing SemVer, disregarding compatibility as a goal, and only releasing fixes (security-related even) for the latest major version that came out several months ago, or abandoning them. Yeah, that's some serious BS and I hope things mature.
gareim 12y ago
I just started learning Rails and haven't deployed yet, but the thought of upgrading after deploying a project scares me a lot.
- patrickdavey 12y ago
  Why does it scare you? It's good to be wary of the upgrade process.. but this is why you have (I hope!) database backups and source control (as a minimum). Then at least you can roll back. Then it's just extras after that, test coverage, staging servers etc. etc. Anyway, upgrading is a fact of life once you're using a framework (unless you want to get hacked) so best to get used to it :) Good luck!
- diasks2 12y ago
  I've found the best way to make upgrading easier is having good test coverage. I think one of the biggest fears when upgrading is having something break but not knowing that it is now broken. Although tests won't always catch everything they are a great start to ease the upgrade process.
- cies 12y ago
  To have tests (and particularly integration tests) is a big help; as has already been mentioned. Another thing is to use staged deployments: dont deploy to production-env from you development-env, but to a staging-env (if possible using the same or a copy of the live database). Then have a look with some (possibly non-technical) humans if the app still behaves as expected. While it can be laborious for a large app, it should make a deployment to production a lot less scary. As mentioned by others: upgrading is part of running a web app that depends on popular libs.
deleted 12y ago
[deleted]
whistlerbrk 12y ago
I don't. I feel like the deprecations and API changes have mostly been quite minor since 4.x. A lot of this is shedding weight from supporting Ruby 1.9 and 1.8.7, so if you've been up to date on that front (gem and code wise) you've been okay. I'm looking forward to 5, but I'd like to see what the feature set is. Namely building real time and concurrent apps in _Ruby_ doesn't feel natural on _Rails_ and I hope it can be.
douglasfshearer 12y ago
Rails used as intended can be a real pain to upgrade, I agree. Recently I have been developing applications in the "thin-model, thin-controller, with a service layer and external API wrappers" style, as espoused by Gary Bernhardt [1] and others [2] [3] [4] [5]. I upgraded to the latest Rails this morning on one app, and apart from swapping the Money gem to use the git repository, until they have a new version out with compatible dependency, it went smoothly. All the specs and acceptance tests passing with no alteration required. [1] https://github.com/garybernhardt/sucks-rocks https://github.com/garybernhardt/sucks-rocks [2] http://jamesgolick.com/2010/3/14/crazy-heretical-and-awesome-the-way-i-write-rails-apps.html http://jamesgolick.com/2010/3/14/crazy-heretical-and-awesome... [3] http://objectsonrails.com/ http://objectsonrails.com/ [4] http://solnic.eu/2011/08/01/making-activerecord-models-thin.html http://solnic.eu/2011/08/01/making-activerecord-models-thin.... [5] https://www.youtube.com/watch?v=CGN4RFkhH2M https://www.youtube.com/watch?v=CGN4RFkhH2M
- rapind 12y ago
  Anyone else thinking "EJB on Rails"?
mbesto 12y ago
I'd love for Rails to have some incremental LTS releases. Not that the Rails organization itself has to provide support, but rather the community decides which releases are most suited for LTS support. This would force gem providers (and automated CI's) to test on those releases.
- alxndr 12y ago
  Have you seen https://railslts.com/ https://railslts.com/ ? > "Rails LTS is a commercially supported fork of Rails 2.3 (and soon Rails 3.2) that continues to receive security patches now that official support has ended."
websitescenes 12y ago
Upgrading between from 2.x to 3.x or 3.x to 4.x can tend to be tricky but I have not had many, if any, issues upgrading from 4.x to 4.2. Typically if a functionality is removed or deprecated from the framework, you will find a gem will popup that can be included so your legacy code still functions. I often take this approach since we maintain mountains of Rails apps from 2.x to 4.x. If you are working on a handful of apps or a single app, I think it is worth it to stay as current as possible and update with every new release. Your knowledge of the framework and the quality of the product will increase with every iteration.
hmans 12y ago
Unless you need one of the new features on offer, there is no reason why you would need to upgrade right away. It's perfectly okay to give a new Rails release a couple of months to settle, including gems that need to be compatible with it.

TallboyOne 12y ago

I'm just waiting on Delayed Job at this point :)

reledi 12y ago
What do you mean? Is DJ supposed to become a Rails built-in library?
- brandoncordell 12y ago
  No, but Rails has ActiveJob[1] which allows you to use backends interchangeably (see heading 4.1 of the link I posted). [1] http://edgeguides.rubyonrails.org/active_job_basics.html http://edgeguides.rubyonrails.org/active_job_basics.html
xal 12y ago
DJ could use a update to be fully Rails 4.2 compatible. I'd love a PR for that and would merge. https://github.com/tobi/delayed_job https://github.com/tobi/delayed_job
- reledi 12y ago
  The repo you linked to is dead. DJ is in active development at https://github.com/collectiveidea/delayed_job https://github.com/collectiveidea/delayed_job.
deleted 12y ago
[deleted]

reledi 12y ago

Seasons greetings Rails team; thanks for the gifts.

MaxGabriel 12y ago

Has anyone had issues upgrading? Alot of our tests that check a value from a the session are failing; haven't been able to figure out why so far.

cpg 12y ago
https://github.com/binarylogic/authlogic/issues/432 https://github.com/binarylogic/authlogic/issues/432

sergiotapia 12y ago

The Rails team make so many developers happy worldwide, it's incredible. Thank you from the bottom of my heart for making my job suck less. --- A quick questions regarding Foreign Key support, in the past I would use these concepts normally but does this mean that before Rails did not use Foreign Keys (in the strict rdbms sense)? Does this mean that there are now easy performance gains if you're using their new -real- foreign key support?

amalag 12y ago
To your first question, Rails tried to enforce some constraints at the application level, but it was lacking. I worked in a large production system and for extra safeguards their were DB level foreign key constraints. They are kind of a pain to unwind and make changes, but they can save your butt if you accidentally delete something. Second question: You can see this answer: http://stackoverflow.com/questions/507179/does-foreign-key-improve-query-performance http://stackoverflow.com/questions/507179/does-foreign-key-i...
- ikawe 12y ago
  Read more about the shortcomings of application level reference validations here: http://robots.thoughtbot.com/referential-integrity-with-foreign-keys http://robots.thoughtbot.com/referential-integrity-with-fore... Note: that post talks about using `foreigner` gem which predates having foreign key support in rails core.
ikawe 12y ago
Using `belongs_to` or `references` in a migration is simply an alias for an integer column (that conventionally holds the id of another row) without any foreign key constraints. Foreign key constraints aren't about performance - they are about maintaining [referential integrity]. previously... pet.id # => 4 owner.update_attribute(:pet_id, 4) pet.destroy owner.pet # what should this equal? Now this will throw an error. pet.id # => 4 owner.update_attribute(:pet_id, 4) pet.destroy # <= raises Error:trying to destroy a record that is referenced by the owners table. owner.update_attribute(:pet_id, nil) pet.destroy # no problem now. [referential integrity] http://en.wikipedia.org/wiki/Referential_integrity http://en.wikipedia.org/wiki/Referential_integrity

andyl 12y ago

Rails4.2 the day after Postgres9.4. A great combination. Postgres9.4 has JsonB, Json, Hstore and Array fields. Rails4.2 fixes the dirty-tracking for JsonB/Json/Hstore. Thank you developers!

jrochkind1 12y ago
> Postgres9.4 has JsonB, Json, Hstore and Array fields. Rails4.2 fixes the dirty-tracking for JsonB/Json/Hstore. Oh, I hadn't caught that, awesome! Can you link to docs and/or commit? I'm wondering if it will do "partial updates" yet -- postgres supports, I think for Json too but definitely for Hstore, a statement that says "just update these keys with these values, leave the other key/values alone". The reason you'd be interested in this is multi-client concurrency, so one client updating some keys doesn't overwrite changes made at about the same time by another client updating only other keys. Lets you use hstore/json in certain circumstances of multi-process concurrency that otherwise you'd have to use normalized separate rows for. When I had tried to look at ActiveRecord on my own to figure out if I could get it to do this, it seemed like it oughta be possible (AR is already tracking the original value for dirty tracking, I think) but I never quite could figure it out, how to hook into the SQL-generation to do it.

deleted 12y ago

[deleted]

gfodor 12y ago

Congrats, and thanks so much for your hard work rails team.

poppup 12y ago

I have been using rails for many years now and I'm sad to say I'm leaving it behind in my current/new project :( I will miss the familiar patterns and want to express my gratitude to the team that makes everything work so seamlessly.

copperx 12y ago
Which framework will you be using now?
nilved 12y ago
What are you using instead?

ghiculescu 12y ago

I found http://samsaffron.com/archive/2014/12/01/speeding-up-rails-4-2 http://samsaffron.com/archive/2014/12/01/speeding-up-rails-4... (from the post's comments) interesting. It looks like there were initially quite a few performance regressions in the new release. Adequate Record looks great for rails scaffolds, but (at this stage) doesn't look like it will very useful for production apps that probably have more complex queries. For example, it stops working if your query has a `where`. Big thanks to Sam et al for their work in speeding things up.

izietto 12y ago

Finally official foreign keys support \o/