aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/lib/active_record/relation/query_methods.rb
Commit message (Collapse)AuthorAgeFilesLines
* Extract a Relation#arel_attributeMatthew Draper2016-02-041-4/+4
|
* Defer Arel attribute lookup to the model classMatthew Draper2016-02-041-7/+5
| | | | | This still isn't as separated as I'd like, but it at least moves most of the burden of alias mapping in one place.
* Introduce ActiveRecord::IrreversibleOrderErrorBogdan Gusiev2016-01-271-2/+16
| | | | | Raises when #reverse_order can not process SQL order instead of making invalid SQL before this patch
* Improve error message for #or when it is structurally incompatibleRafael Mendonça França2016-01-131-6/+8
| | | | | | | | When you are using scopes and you chaining these scopes it is hard to know which are the values that are incompatible. This way you can read the message and know for which values you need to look for. [Herminio Torres]
* activerecord: reuse immutable objectsTamir Duberstein2016-01-041-10/+12
|
* Improve example of #or to use different column values in the where clausesTim Sandberg2015-12-301-2/+2
|
* remove extra spaces from deprecation messageyuuji.yaginuma2015-12-151-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ``` # before DEPRECATION WARNING: Time columns will become time zone aware in Rails 5.1. This still causes `String`s to be parsed as if they were in `Time.zone`, and `Time`s to be converted to `Time.zone`. To keep the old behavior, you must add the following to your initializer: config.active_record.time_zone_aware_types = [:datetime] To silence this deprecation warning, add the following: config.active_record.time_zone_aware_types << :time ``` ``` # after DEPRECATION WARNING: Time columns will become time zone aware in Rails 5.1. This still causes `String`s to be parsed as if they were in `Time.zone`, and `Time`s to be converted to `Time.zone`. To keep the old behavior, you must add the following to your initializer: config.active_record.time_zone_aware_types = [:datetime] To silence this deprecation warning, add the following: config.active_record.time_zone_aware_types << :time ```
* Use a bind param for `LIMIT` and `OFFSET`Sean Griffin2015-12-141-4/+30
| | | | | | | | | | | | | | | We currently generate an unbounded number of prepared statements when `limit` or `offset` are called with a dynamic argument. This changes `LIMIT` and `OFFSET` to use bind params, eliminating the problem. `Type::Value#hash` needed to be implemented, as it turns out we busted the query cache if the type object used wasn't exactly the same object. This drops support for passing an `Arel::Nodes::SqlLiteral` to `limit`. Doing this relied on AR internals, and was never officially supported usage. Fixes #22250.
* Deprecate limit strings with commasSean Griffin2015-12-141-0/+6
| | | | | | | | | | Some backends allow `LIMIT 1,2` as a shorthand for `LIMIT 1 OFFSET 2`. Supporting this in Active Record massively complicates using bind parameters for limit and offset, and it's trivially easy to build an invalid SQL query by also calling `offset` on the same `Relation`. This is a niche syntax that is only supported by a few adapters, and can be trivially worked around by calling offset explicitly.
* Docs: ActiveRecord::QueryMethods#joinsJared Beck2015-11-251-2/+22
| | | | [ci skip]
* Update and fix forbidden attributes testsThomas Walpole2015-11-031-0/+4
| | | | Add AC::Parameters tests for WhereChain#not
* Define `sanitize_sql_for_order` for AR and use it inside `preprocess_order_args`yui-knk2015-11-021-5/+1
| | | | This commit follows up of 6a6dbb4c51fb0c58ba1a810eaa552774167b758a.
* Alias left_joins to left_outer_joinsTakashi Kokubun2015-10-311-0/+2
|
* Merge pull request #12071 from Crunch09/outer_joinsSean Griffin2015-10-301-1/+39
|\ | | | | | | added ActiveRecord::Relation#outer_joins
| * added ActiveRecord::Relation#left_outer_joinsFlorian Thomas2015-05-191-1/+39
| | | | | | | | | | | | Example: User.left_outer_joins(:posts) => SELECT "users".* FROM "users" LEFT OUTER JOIN "posts" ON "posts"."user_id" = "users"."id"
* | Merge pull request #13008 from ktheory/sanitize_orderSean Griffin2015-10-291-0/+7
|\ \ | | | | | | | | | Support SQL sanitization in AR::QueryMethods#order
| * | Support SQL sanitization in AR::QueryMethods#orderAaron Suggs2013-11-221-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Add support for sanitizing arrays in SQL ORDER clauses. This is useful when using MySQL `ORDER BY FIELD()` to return records in a predetermined way. ```ruby Tag.order(['field(id, ?', [1,3,2]].to_sql # => SELECT "tags".* FROM "tags" ORDER BY field(id, 1,3,2) ``` Prior to this, developers must be careful to sanitize `#order` arguments themselves.
* | | Do not omit parentheses [ci skip]Ryuta Kamizono2015-10-251-1/+1
| | |
* | | Green version of moving the handling of supported arguments to `where`yui-knk2015-10-181-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | This commit follow up of 4d8f62d. The difference from 4d8f62d are below: * Change `WhereClauseFactory` to accept `Arel::Nodes::Node` * Change test cases of `relation_test.rb`
* | | Revert "Move the handling of supported arguments to `where`"Rafael Mendonça França2015-10-171-0/+2
| | | | | | | | | | | | | | | | | | This reverts commit 4d8f62dcfa0a5157b3facbd71f75fc6639636347. Reason: This broke the build. Please recommit again when it is green.
* | | Move the handling of supported arguments to `where`Sean Griffin2015-10-161-2/+0
| | | | | | | | | | | | | | | | | | `WhereClauseFactory` handles all other branches based on argument types, so the code fits more naturally here, and it's just where the responsibility belongs.
* | | `where` raises ArgumentError on unsupported types.Jake Worth2015-10-161-0/+2
| | | | | | | | | | | | [#20473]
* | | applies new doc guidelines to Active Record.Yves Senn2015-10-141-17/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The focus of this change is to make the API more accessible. References to method and classes should be linked to make it easy to navigate around. This patch makes exzessiv use of `rdoc-ref:` to provide more readable docs. This makes it possible to document `ActiveRecord::Base#save` even though the method is within a separate module `ActiveRecord::Persistence`. The goal here is to bring the API closer to the actual code that you would write. This commit only deals with Active Record. The other gems will be updated accordingly but in different commits. The pass through Active Record is not completely finished yet. A follow up commit will change the spots I haven't yet had the time to update. /cc @fxn
* | | `private def` breaks RDoc. Move meathod to preserve the docs.Yves Senn2015-10-131-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The rdoc parser seems to trip on the `private def` construct. Public methods following a method defined with `private def` are not visible inside the module docs but are appended to the top-most module. For example the method `ActiveRecord::QueryMethods#distinct` was listed under `ActiveRecord#distinct`. /cc @sgrif
* | | docs, recognize code examples as Ruby in `Relation::QueryMethods` [ci skip]Yves Senn2015-10-131-33/+37
| | | | | | | | | | | | | | | | | | | | | | | | Also unify the format of code example output. Only use `# =>` if the actual return value is described. Otherwise simply use `#`. Conflicts: activerecord/lib/active_record/relation/query_methods.rb
* | | Remove unused requireakihiro172015-10-081-1/+0
| | | | | | | | | | | | `require 'active_support/core_ext/string/filters'` was added in b3bfa36. However, it is no longer needed from 3ae981814.
* | | Fix AC::Parameters not being sanitized for query methods.Guo Xiang Tan2015-10-021-5/+3
| | |
* | | Correcting `ActiveRecord::ReadOnlyRecord` Error Message [ci skip]amitkumarsuroliya2015-09-261-1/+1
| | |
* | | docs, add missing closing bracket. [ci skip]amitkumarsuroliya2015-09-251-1/+1
| | |
* | | Ensure aliased attributes passed to `select` are quoted if using `from`Sean Griffin2015-09-211-1/+1
| | | | | | | | | | | | | | | | | | Fixes #21488 [Sean Griffin & johanlunds]
* | | #where fails if opts.responds_to?(:==) unexpectedlySamuel Williams2015-09-051-1/+1
| | | | | | | | | Sometimes opts passed in might respond to ==, e.g. `Arel::Nodes::Grouping`. In this case, `opts == :chain` returns `Arel::Nodes::Equality` which causes odd behaviour. Prefer `if :chain == opts` which guarantees that `Symbol#==` would be invoked. Alternatively consider `eql?`.
* | | Include `Enumerable` in `ActiveRecord::Relation`Sean Griffin2015-06-191-6/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | After discussing, we've decided it makes more sense to include it. We're already forwarding every conflicting method to `to_a`, and there's no conflation of concerns. `Enumerable` has no mutating methods, and it just allows us to simplify the code. No existing methods will have a change in behavior. Un-overridden Enumerable methods will simply delegate to `each`. [Sean Griffin & bogdan]
* | | Ensure symbols passed to `select` are always quotedSean Griffin2015-05-301-9/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Our general contract in Active Record is that strings are assumed to be SQL literals, and symbols are assumed to reference a column. If a from clause is given, we shouldn't include the table name, but we should still quote the value as if it were a column. Upon fixing this, the tests were still failing on SQLite. This was because the column name being returned by the query was `"\"join\""` instead of `"join"`. This is actually a bug in SQLite that was fixed a long time ago, but I was using the version of SQLite included by OS X which has this bug. Since I'm guessing this will be a common case for contributors, I also added an explicit check with a more helpful error message. Fixes #20360
* | | deprecate `Relation#uniq` use `Relation#distinct` instead.Yves Senn2015-05-261-1/+3
| |/ |/| | | | | | | | | | | | | | | See #9683 for the reasons we switched to `distinct`. Here is the discussion that triggered the actual deprecation #20198. `uniq`, `uniq!` and `uniq_value` are still around. They will be removed in the next minor release after Rails 5.
* | Fix c479480638508c20601af69ca46b5b606c2d5b4d to account for from_value -> ↵Jeremy Kemper2015-02-241-1/+1
| | | | | | | | from_clause in bdc5141652770fd227455681cde1f9899f55b0b9
* | Merge pull request #18744 from mfazekas/no-table-name-with-fromRafael Mendonça França2015-02-241-5/+9
| | | | | | | | Fix appending table_name to select and group when used with subquery (fr...
* | Fixed AR::Relation#group method when argument is a SQL reserved keywordBogdan Gusiev2015-01-291-13/+15
| |
* | Bring the implementation of Relation#or up to speedSean Griffin2015-01-281-36/+8
| |
* | Added #or to ActiveRecord::RelationMatthew Draper2015-01-281-0/+59
| | | | | | | | | | | | | | Post.where('id = 1').or(Post.where('id = 2')) # => SELECT * FROM posts WHERE (id = 1) OR (id = 2) [Matthew Draper & Gael Muller]
* | Remove Relation#bind_paramsSean Griffin2015-01-271-10/+1
| | | | | | | | | | | | | | | | `bound_attributes` is now used universally across the board, removing the need for the conversion layer. These changes are mostly mechanical, with the exception of the log subscriber. Additional, we had to implement `hash` on the attribute objects, so they could be used as a key for query caching.
* | Use an `Attribute` object to represent a bind valueSean Griffin2015-01-271-1/+11
| | | | | | | | | | | | | | | | | | | | | | The column is primarily used for type casting, which we're trying to separate from the idea of a column. Since what we really need is the combination of a name, type, and value, let's use the object that we already have to represent that concept, rather than this tuple. No consumers of the bind values have been changed, only the producers (outside of tests which care too much about internals). This is *finally* possible since the bind values are now produced from a reasonable number of lcoations.
* | Minor refactorings on `Relation#build_joins`Sean Griffin2015-01-271-26/+13
| | | | | | | | Attempting to grok this code by refactoring it as I go through it.
* | Use the `WhereClause` ast building logic for havingSean Griffin2015-01-271-4/+1
| |
* | Move where grouping into `WhereClause`Sean Griffin2015-01-271-11/+1
| |
* | Unify access to bind values on RelationSean Griffin2015-01-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The bind values can come from four places. `having`, `where`, `joins`, and `from` when selecting from a subquery that contains binds. These need to be kept in a specific order, since the clauses will always appear in that order. Up until recently, they were not. Additionally, `joins` actually did keep its bind values in a separate location (presumably because it's the only case that people noticed was broken). However, this meant that anything accessing just `bind_values` was broken (which most places were). This is no longer possible, there is only a single way to access the bind values, and it includes joins in the proper location. The setter was removed yesterday, so breaking `+=` cases is not possible. I'm still not happy that `joins` is putting it's bind values on the Arel AST, and I'm planning on refactoring it further, but this removes a ton of bug cases.
* | Move the `from` bind logic to a `FromClause` classSean Griffin2015-01-261-12/+13
| | | | | | | | | | | | | | Contrary to my previous commit message, it wasn't overkill, and led to much cleaner code. [Sean Griffin & anthonynavarre]
* | Remove `Relation#bind_values=`Sean Griffin2015-01-261-7/+4
| | | | | | | | | | | | | | | | | | | | The last place that was assigning it was when `from` is called with a relation to use as a subquery. The implementation was actually completely broken, and would break if you called `from` more than once, or if you called it on a relation, which also had its own join clause, as the bind values would get completely scrambled. The simplest solution was to just move it into its own array, since creating a `FromClause` class for this would be overkill.
* | Remove unused `bind` and `bind!` methods from `Relation`Sean Griffin2015-01-261-9/+0
| |
* | Remove `Relation#build_where`Sean Griffin2015-01-261-6/+0
| | | | | | | | All of its uses have been moved to better places
* | Change `having_values` to use the `WhereClause` classSean Griffin2015-01-261-3/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixed an issue where `having` can only be called after the last call to `where`, because it messes with the same `bind_values` array. With this change, the two can be called as many times as needed, in any order, and the final query will be correct. However, once something assigns `bind_values`, that stops. This is because we have to move all of the bind values from the having clause over to the where clause since we can't differentiate the two, and assignment was likely in the form of: `relation.bind_values += other.bind_values` This will go away once we remove all places that are assigning `bind_values`, which is next on the list. While this fixes a bug that was present in at least 4.2 (more likely present going back as far as 3.0, becoming more likely in 4.1 and later as we switched to prepared statements in more cases), I don't think this can be easily backported. The internal changes to `Relation` are non-trivial, anything that involves modifying the `bind_values` array would need to change, and I'm not confident that we have sufficient test coverage of all of those locations (when `having` was called with a hash that could generate bind values). [Sean Griffin & anthonynavarre]
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-05 13:01:02 +0000