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.
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.
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.
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
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.
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.
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!
> "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."
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.
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!
---
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?
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?
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.
Second question: You can see this answer: http://stackoverflow.com/questions/507179/does-foreign-key-i...
Note: that post talks about using `foreigner` gem which predates having foreign key support in rails core.
There are pending issues on activerecord-jdbc: https://github.com/jruby/activerecord-jdbc-adapter/issues/59...
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.
[1] http://edgeguides.rubyonrails.org/active_job_basics.html
Postgres9.4 has JsonB, Json, Hstore and Array fields. Rails4.2 fixes the dirty-tracking for JsonB/Json/Hstore. Thank you developers!
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.