aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/lib/active_record/relation/query_methods.rb
Commit message (Collapse)AuthorAgeFilesLines
* Merge pull request #12011 from jetthoughts/11963_fix_join_with_association_scopeRafael Mendonça França2013-09-161-6/+5
|\ | | | | | | | | | | | | Collapse where constraints to the Arel::Nodes::And node Conflicts: activerecord/CHANGELOG.md
| * Collapse where constraints to one where constraintPaul Nikitochkin2013-09-131-6/+5
| | | | | | | | | | | | | | In order to remove duplication with joining arel where constraints with `AND`, all constraints on `build_arel` are collapsed into one head node: `Arel::Nodes::And` Closes: #11963
* | Allow Relation#from to accept other relations with bind values.Ryan Wallace2013-09-081-0/+1
|/
* Extracted from `order` processing of arguments, and use it for `reorder` to ↵Paul Nikitochkin2013-09-041-13/+16
| | | | be consistent.
* Minor optimization and code cleanup in query_methods.Eugene Gilburg2013-07-311-38/+45
| | | | | | | | - Use symbols rather than strings where possible to avoid extra object construction - Use destructive methods where possible to avoid extra object construction - Use array union rather than concat followed by uniq - Use shorthand block syntax where possible - Use consistent multiline block styles, method names, method parenteses style, and spacing
* Revert change on ActiveRecord::Relation#order method that prepends newRafael Mendonça França2013-07-291-2/+2
| | | | | | | | | | | | | | | order on the old ones The previous behavior added a major backward incompatibility since it impossible to have a upgrade path without major changes on the application code. We are taking the most conservative path to be consistent with the idea of having a smoother upgrade on Rails 4. We are reverting the behavior for what was in Rails 3.x and, if needed, we will implement a new API to prepend the order clauses in Rails 4.1.
* Improve ActiveRecord::QueryMethods#includes docsHenrik Hodne2013-07-171-0/+8
| | | | | | | | It's not immediately clear whether you can pass in multiple relations or not. After going through the code a bit, I saw that the arguments are just appended to an array. Also, added nested relations example. [ci skip]
* decouple the manager class from building join constraintsAaron Patterson2013-07-161-4/+5
|
* save another array allocationAaron Patterson2013-07-151-1/+1
|
* removing useless assingmentAaron Patterson2013-07-151-1/+1
|
* use arel rather than slapping together SQL stringsAaron Patterson2013-07-151-2/+4
|
* Blacklist->whitelist for reference scans in order!Ernie Miller2013-07-141-1/+1
| | | | | | Stop special-casing Arel::Nodes as exempt from reference scanning in order. Instead, only scan order values that are strings for a table reference.
* resolve aliases before passing the hash to the predicate builderAaron Patterson2013-07-021-0/+1
|
* Simplify/fix implementation of default scopesJon Leighton2013-06-281-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The previous implementation was necessary in order to support stuff like: class Post < ActiveRecord::Base default_scope where(published: true) scope :ordered, order("created_at") end If we didn't evaluate the default scope at the last possible moment before sending the SQL to the database, it would become impossible to do: Post.unscoped.ordered This is because the default scope would already be bound up in the "ordered" scope, and therefore wouldn't be removed by the "Post.unscoped" part. In 4.0, we have deprecated all "eager" forms of scopes. So now you must write: class Post < ActiveRecord::Base default_scope { where(published: true) } scope :ordered, -> { order("created_at") } end This prevents the default scope getting bound up inside the "ordered" scope, which means we can now have a simpler/better/more natural implementation of default scoping. A knock on effect is that some things that didn't work properly now do. For example it was previously impossible to use #except to remove a part of the default scope, since the default scope was evaluated after the call to #except.
* flatten merged join_values before building the joinsNeeraj Singh2013-06-221-1/+1
| | | | | | | | fixes #10669 While joining_values special treatment is given to string values. By flattening the array it ensures that string values are detected as strings and not arrays.
* Merge pull request #10767 from jmondo/masterCarlos Antonio da Silva2013-05-291-1/+1
|\ | | | | Use grep instead of select with === in QueryMethods
| * use grep over select for consistency and efficiencyJohn Gesimondo2013-05-281-1/+1
| | | | | | | | pass block directly to grep
* | `implicit_readonly` is being removed in favor of calling `readonly` explicitlyYves Senn2013-05-271-5/+0
|/
* added to rdoc for unscope that default_scope winsNeeraj Singh2013-05-031-0/+3
|
* When empty options passed to having clause having_values was [nil] but ↵Fyodor2013-04-231-1/+0
| | | | should be empty.
* Merge branch 'master' of github.com:lifo/docrailsVijay Dev2013-04-111-2/+1
|\ | | | | | | | | Conflicts: guides/source/action_mailer_basics.md
| * mark relation mutator as :nodoc: [ci skip]Francesco Rodriguez2013-04-021-2/+1
| |
* | converge three lines into oneNeeraj Singh2013-04-101-3/+1
|/
* Fix some typos in AR- CHANGELOG, tests, method doc. fixedVipul A M2013-03-201-1/+1
|
* rename `Relation#uniq` to `Relation#distinct`. `#uniq` still works.Yves Senn2013-03-151-9/+11
| | | | | | | | The similarity of `Relation#uniq` to `Array#uniq` is confusing. Since our Relation API is close to SQL terms I renamed `#uniq` to `#distinct`. There is no deprecation. `#uniq` and `#uniq!` are aliases and will continue to work. I also updated the documentation to promote the use of `#distinct`.
* Merge branch 'master' of github.com:lifo/docrailsVijay Dev2013-03-051-1/+1
|\
| * Fix WhereChain docs to mention only notErnie Miller2013-03-041-1/+1
| |
* | Remove .all usage from unscope doc examples [ci skip]Carlos Antonio da Silva2013-03-041-4/+4
| |
* | Use 1.9 hash style in changelog and doc examples [ci skip]Carlos Antonio da Silva2013-03-041-3/+3
| |
* | Created an unscope method for removing relations from a chain ofwangjohn2013-03-031-0/+94
|/ | | | | relations. Specific where values can be unscoped, and the unscope method still works when relations are merged or combined.
* Expand order(:symbol) to "table".symbol to prevent broken queries on PG.Yves Senn2013-02-251-0/+5
| | | | | | | | | | Fixes #9275. When `#order` is called with a Symbol this patch will prepend the quoted_table_name. Before the postgresql adapter failed to build queries containg a join and an order with a symbol. This expansion happens for all adapters.
* Make explicit the method will raise an exceptionRafael Mendonça França2013-02-241-10/+10
| | | | Taking the wise advice of @carlosantoniodasilva
* Merge pull request #9345 from ↵Rafael Mendonça França2013-02-201-10/+10
|\ | | | | | | | | wangjohn/change_name_of_query_method_argument_checker_for_clarity Renaming the check_empty_arguments method to something more descriptive.
| * Renaming the check_empty_arguments method to something more descriptive.wangjohn2013-02-201-10/+10
| | | | | | | | | | The function is now called has_arguments? so that it's easier to tell that it's just checking to see if the args are blank or not.
* | removes some remaining relation bang methods documentation [ci skip]Xavier Noria2013-02-201-3/+0
| |
* | adds an example in the docs of #not with multiple conditions [ci skip]Xavier Noria2013-02-201-4/+8
|/
* Added comments about the check_empty_arguments method which is calledwangjohn2013-02-201-11/+27
| | | | | for query methods in a where_clause. Also, modified the CHANGELOG entry because it had false information and added tests.
* Raise an error when query methods have blank arguments, and when blank ↵John J Wang2013-02-191-9/+23
| | | | arguments are meaningless.
* Add example for ActiveRecord::Base.joins using a string as argumentMaurizio De Santis2013-02-071-0/+5
|
* Add example for ActiveRecord::Base.group using a string as argumentMaurizio De Santis2013-02-071-0/+3
|
* Add documentation for ActiveRecord.select when use strings as argumentsMaurizio De Santis2013-02-071-0/+10
|
* reduce the number of queries on IN clauses, fix relation queries in `where`Aaron Patterson2013-01-241-0/+5
|
* Improve where.not docs [ci skip]Carlos Antonio da Silva2012-12-081-14/+8
| | | | | | | * Fix example queries * Remove doc entries of where.like/not_like. * Remove :chain from where.not related docs. To me that's an implementation detail and we don't expect people to use where(:chain).not.
* Rollback where.like and where.not_likeCarlos Antonio da Silva2012-12-071-26/+0
| | | | | | | | | | | | | | | | | | | The real win with these chain methods is where.not, that takes care of different scenarios in a graceful way, for instance when the given value is nil. where("author.id != ?", author_to_ignore.id) where.not("author.id", author_to_ignore.id) Both where.like and where.not_like compared to the SQL versions doesn't seem to give us that much: Post.where("title LIKE 'ruby on%'") Post.where.like(title: 'ruby on%'") Post.where("title NOT LIKE 'ruby on%'") Post.where.not_like(title: 'ruby on%'") Thus Rails is adding where.not, but not where.like/not_like and others.
* Document the types of arguments accepted by AR#notclaudiob2012-12-071-2/+11
| | | | | | | | This commit stems from https://github.com/rails/rails/pull/8332#issuecomment-11127957 Since the formats in which conditions can be passed to `not` differ from the formats in which conditions can be passed to `like` and `not_like`, then I think it's worth adding rdoc and tests to show this behavior
* Fix where.not with in clauseCarlos Antonio da Silva2012-12-071-3/+3
| | | | | | Arel::Nodes::In inherits from Arel::Nodes::Equality, so the case statement was always using the Equality operator for both scenarios, resulting in a not equal query instead.
* Update #where rdoc to match 6ba0f97 [ci skip]claudiob2012-12-071-4/+4
| | | | | | | | This commit updates the rdoc of AR#where to match the changes applied in https://github.com/rails/rails/commit/6ba0f97 that is: * `where(nil)` has the same effect of `where('')`: a no op * `where` (no args) has the same effect of `where(:chain)`: to create a WhereChain
* Ensure there won't be any regression with where(nil) callsCarlos Antonio da Silva2012-12-071-4/+4
| | | | | | | | | | | | | | | | | | | Consider this scenario: if params[:foo] conditions = { foo: true } end foos = Foo.where(conditions).order(:id) When params[:foo] is nil, this would call: foos = Foo.where(nil).order(:id) In this scenario, we want Foo.where(conditions) to be the same as calling Foo.all, otherwise we'd get a "NoMethodError order for WhereChain". Related to #8332.
* Merge pull request #8332 from amatsuda/ar_where_chainCarlos Antonio da Silva2012-12-071-7/+98
|\ | | | | | | | | | | | | | | Relation.where with no args can be chained with not, like, and not_like Conflicts: activerecord/CHANGELOG.md activerecord/lib/active_record/relation/query_methods.rb
| * Relation.where with no args can be chained with not, like, and not_likeAkira Matsuda2012-11-301-7/+96
| | | | | | | | | | | | | | | | | | | | | | | | | | | | examples: Model.where.not field: nil #=> "SELECT * FROM models WHERE field IS NOT NULL Model.where.like name: 'Jeremy%' #=> "SELECT * FROM models WHERE name LIKE 'Jeremy%' this feature was originally suggested by Jeremy Kemper https://github.com/rails/rails/pull/5950#issuecomment-5591330 Closes #5950