This does introduce some fairly fundamental changes in the API. Breaking every book ever written about your framework is fairly ballsy.
In a lot of ways it's the inevitable conclusion of Rails' trend towards named_scope'ing everything. Chaining everything ends up being pretty flexible, even when you're building up things dynamically (I'm seeing a lot of `.send('the_scope')` in my future). And the lazy-loading should be quite helpful.
And the weird side-effect is that you can now write it somewhat as SQL: User.select().from().where(), etc., which conceivably could help those new to the framework.
Really, though, I'm still surprised at the rather large change here. At least it seems we have ample time to start the transition before 3.2 (and, as one commenter mentioned, you could start building your own .where() named_scopes today to somewhat ease the transition).
And the weird side-effect is that you can now write it somewhat as SQL: User.select().from().where(), etc., which conceivably could help those new to the framework.
which kind of defeats (part of) the point of it being a sql abstraction layer, doesn't it? granted, most of activerecord's backends are for sql servers, but now adding a sql-like syntax to other generic (nosql?) backends seems kind of confusing.
personally i wish they'd just keep find() and all the old methods for compatibility. the new stuff is neat but i don't see the point in deprecating and then actually removing the old things that have been around for many years.
Yup, that was my first thought too. But you kind of need to know SQL to really figure out the current API, so maybe moving closer to that isn't a bad idea. In any case, you only need to know the idea of SQL, really, since chainable scopes let you go wild with where().joins().where().where() and you don't have to worry about syntax or aliasing.
You can still use find() through 3.1 (so for at least a number of months I'd expect). At that point, they'll offer backwards compatibility via a plugin, so no worries.
At first glance, this looks like it has "massive rewrite" all over it:-/ It does look nice, but that's a lot of very widely used code that's being deprecated.
This is just the tip of the iceberg in Rails 3. The architectural changes are widespread. Things like routing and generators are straight replaced with much more powerful versions. both those things need to be rewritten on a completely different API. The layout of the API docs is dramatically different with components shifted all over the place. This may well be frustrating to existing app developers who have a more modest pace of development and just want to focus on incremental improvements. However if you look at the modularity and flexibility these changes bring, you'll realize that Rails 3 is now several orders of magnitude more flexible and it becomes viable for a much larger set of problem domains.
The Rails core team is not content to dramatically slow down improvements to accommodate an installed base, they want to take advantage of good ideas and keep Rails at the forefront of web development--and this is not change for change's sake, all the deprecations and outright replacements are well justified.
There's no doubt this will wreak havoc with traditional teams maintaining mature apps that don't have the budget or interest to spend time refactoring existing code. I do feel their pain. But old code still runs. You have the choice of sticking with 2.3.x or else capitalizing on powerful new improvements. The only choice they've taken away is the ability to sort of putter along on a series of bland updates to a mature framework. Maybe that's where Rails will be in another 5 years, but not today.
It does look nice, but that's a lot of very widely used code that's being deprecated.
That's why it's being only deprecated though. Deprecation is a signal to the developer that things are changing. It's the step before terminating support for the code.
I like these changes, personally. I think it makes the code more readable, and lazy loading should help improve performance a bit. I wish ActiveRecord would have declarative attributes à la DataMapper or MongoMapper though.
This is a great change. We almost never use .find() anymore in our rails 2.3 projects and everything uses named_scope() or scoped() (which return relations). This change will discourage really bad practices that I've seen in a lot of rails code.
If you've been doing things right you won't need to change much code. If you've been doing them wrong you will likely see a significant performance increase after updating your code.
Here's a line from our 2.3.2 project (Get all organizations that the user is a fan of):
Fairly much awesome (not totally awesome because I'll have to maintain old projects as-is, not worth updating with so many API changes).
While I use a few different programming languages in my work, I am now fairly much only using Rails for web applications. This process was finalized when I converted a customer's project from Common Lisp to Ruby and Rails last summer.
This is a great change. After you use Sequel for a while (which operates this way) it's really hard to go back to ActiveRecord and pass hashes all over the place.
In a lot of ways it's the inevitable conclusion of Rails' trend towards named_scope'ing everything. Chaining everything ends up being pretty flexible, even when you're building up things dynamically (I'm seeing a lot of `.send('the_scope')` in my future). And the lazy-loading should be quite helpful.
And the weird side-effect is that you can now write it somewhat as SQL: User.select().from().where(), etc., which conceivably could help those new to the framework.
Really, though, I'm still surprised at the rather large change here. At least it seems we have ample time to start the transition before 3.2 (and, as one commenter mentioned, you could start building your own .where() named_scopes today to somewhat ease the transition).