5 ms·

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 t

by holman 17y ago

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 17y ago
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 17y ago
  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.

by holman 17y ago

there 17y ago

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 17y ago
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.