
Active Record Query Interface 3.0 - davidw
http://m.onkey.org/2010/1/22/active-record-query-interface
======
holman
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).

~~~
there
_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.

~~~
holman
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.

------
davidw
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.

~~~
dasil003
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.

------
gdeglin
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):

@user.organizations.scoped(:limit => 10).with_role("Fan")

And what it will look like after this change:

@user.organizations.limit(10).with_role("Fan")

~~~
timmaah
You can do the "after" right now.

named_scope :limit, lambda { |num| { :limit => num } }

------
mark_l_watson
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.

------
pkulak
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.

------
dschobel
Very cool, very LINQish (for the C# lads out there). Includes deferred
execution and everything!

Color me excited.

