Browse files

add changelogs about deprecated stuff [ci skip]

  • Loading branch information...
1 parent 62c6ac2 commit 103ce300ec7507d235ca31efe61033f0b7a601c0 @jonleighton jonleighton committed May 18, 2012
Showing with 55 additions and 1 deletion.
  1. +55 −1 activerecord/
@@ -1,10 +1,64 @@
## Rails 4.0.0 (unreleased) ##
+* Deprecated most of the 'dynamic finder' methods. All dynamic methods
+ except for `find_by_...` and `find_by_...!` are deprecated. Here's
+ how you can rewrite the code:
+ * `find_all_by_...` can be rewritten using `where(...)`
+ * `find_last_by_...` can be rewritten using `where(...).last`
+ * `scoped_by_...` can be rewritten using `where(...)`
+ * `find_or_initialize_by_...` can be rewritten using
+ `where(...).first_or_initialize`
+ * `find_or_create_by_...` can be rewritten using
+ `where(...).first_or_create!`
carlosantoniodasilva May 18, 2012 Member

I think the ! shouldn't be here, not?

jonleighton May 18, 2012 Member

confirm, thanks for proof reading :)

+ * `find_or_create_by_...!` can be rewritten using
+ `where(...).first_or_create!`
+ The implementation of the deprecated dynamic finders has been moved
+ to the `active_record_deprecated_finders` gem. See below for details.
+ *Jon Leighton*
+* Deprecated the old-style hash based finder API. This means that
+ methods which previously accepted "finder options" no longer do. For
+ example this:
+ Post.find(:all, :conditions => { :comments_count => 10 }, :limit => 5)
+ Should be rewritten in the new style which has existed since Rails 3:
+ Post.where(comments_count: 10).limit(5)
+ Note that as an interim step, it is possible to rewrite the above as:
+ Post.scoped(:where => { :comments_count => 10 }, :limit => 5)
+ This could save you a lot of work if there is a lot of old-style
+ finder usage in your application.
+ Calling `Post.scoped(options)` is a shortcut for
+ `Post.scoped.merge(options)`. `Relation#merge` now accepts a hash of
+ options, but they must be identical to the names of the equivalent
+ finder method. These are mostly identical to the old-style finder
+ option names, except in the following cases:
+ * `:conditions` becomes `:where`
+ * `:include` becomes `:includes`
+ * `:extend` becomes `:extending`
+ The code to implement the deprecated features has been moved out to
+ the `active_record_deprecated_finders` gem. This gem is a dependency
+ of Active Record in Rails 4.0. It will no longer be a dependency
+ from Rails 4.1, but if your app relies on the deprecated features
+ then you can add it to your own Gemfile. It will be maintained by
+ the Rails core team until Rails 5.0 is released.
+ *Jon Leighton*
* It's not possible anymore to destroy a model marked as read only.
*Johannes Barre*
* Added ability to ActiveRecord::Relation#from to accept other ActiveRecord::Relation objects

4 comments on commit 103ce30


Why is removing dynamic finders a good idea? They have long been an excellent example of the type of DSL that Rails has often espoused.

They are also easy to use, easy to read, and for beginners, and provide a nice stepping stone to understanding how where clauses work.

Is there a technical reason for their removal that I'm overlooking?


Unless I'm missing something, the answer is right there in the code comments - They're trivial to write using #where

drogus commented on 103ce30 Aug 1, 2012

@JeffCohen DSLs should be used if they give you advantage over regular code. In this case dynamic finders does not give you a lot and they use method missing (which is not bad as a rule, but I think that it should not be used when it's not needed). Also, this is a matter of taste, but for me using where looks cleaner than using long method:

User.find_all_by_first_name_and_last_name 'Piotr', 'Sarnacki'
# vs.
User.where(first_name: 'Piotr', last_name: 'Sarnacki')

It turns out to also be shorter ;)


@grumpit and @drogus thanks for the replies. I still think the fluid form reveals the intention better than a where clause with a hash, even though I'm usually all for shorter code :-)

Please sign in to comment.