Rails 4.2 released

http://weblog.rubyonrails.org/2014/12/19/Rails-4-2-final/

by chancancode • 12 years ago

234 51 12 years ago

weblog.rubyonrails.org

te_chris• 12 years ago

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

amalag2• 12 years ago

Rails 4.2 does NOT work with JRuby.

There are pending issues on activerecord-jdbc: https://github.com/jruby/activerecord-jdbc-adapter/issues/59...

ma2ge• 12 years ago

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

jrochkind12• 12 years 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• 12 years 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!

reledi4• 12 years 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• 12 years 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/ comes in.

username2232• 12 years 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.

tomcam2• 12 years 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.

lotyrin2• 12 years 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• 12 years 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• 12 years 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• 12 years 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• 12 years 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.

whistlerbrk• 12 years 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• 12 years 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 [2] http://jamesgolick.com/2010/3/14/crazy-heretical-and-awesome... [3] http://objectsonrails.com/ [4] http://solnic.eu/2011/08/01/making-activerecord-models-thin.... [5] https://www.youtube.com/watch?v=CGN4RFkhH2M

rapind• 12 years ago

Anyone else thinking "EJB on Rails"?

mbesto• 12 years 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• 12 years ago

Have you seen 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• 12 years 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• 12 years 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• 12 years ago

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

reledi4• 12 years ago

What do you mean? Is DJ supposed to become a Rails built-in library?

brandoncordell• 12 years 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

xal• 12 years 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

reledi4• 12 years ago

The repo you linked to is dead. DJ is in active development at https://github.com/collectiveidea/delayed_job.

reledi4• 12 years ago

Seasons greetings Rails team; thanks for the gifts.

MaxGabriel• 12 years 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• 12 years ago

https://github.com/binarylogic/authlogic/issues/432

sergiotapia• 12 years 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?

amalag2• 12 years 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-i...

ikawe2• 12 years ago

Read more about the shortcomings of application level reference validations here: 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.

ikawe2• 12 years 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

andyl• 12 years 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!

jrochkind12• 12 years 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.

gfodor• 12 years ago

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

poppup• 12 years 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• 12 years ago

Which framework will you be using now?

nilved• 12 years ago

What are you using instead?

ghiculescu• 12 years ago

I found 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• 12 years ago

Finally official foreign keys support \o/

Rails 4.2 released

Related Stories