aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/lib/active_record/relation
Commit message (Collapse)AuthorAgeFilesLines
* remove warnings from FinderMethodsyuuji.yaginuma2016-02-111-4/+4
| | | | | | | | | | | This removes the following warnings. ``` activerecord/lib/active_record/relation/finder_methods.rb:252: warning: ambiguous first argument; put parentheses or a space even after `-' operator activerecord/lib/active_record/relation/finder_methods.rb:258: warning: ambiguous first argument; put parentheses or a space even after `-' operator activerecord/lib/active_record/relation/finder_methods.rb:268: warning: ambiguous first argument; put parentheses or a space even after `-' operator activerecord/lib/active_record/relation/finder_methods.rb:274: warning: ambiguous first argument; put parentheses or a space even after `-' operator ```
* rename to 'second_to_last' and 'third_to_last'Brian Christian2016-02-101-12/+12
|
* allow Array.penultimate and Array.antepenultiate access methodsBrian Christian2016-02-091-0/+32
|
* Extract a Relation#arel_attributeMatthew Draper2016-02-045-11/+11
|
* Defer Arel attribute lookup to the model classMatthew Draper2016-02-045-23/+13
| | | | | 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.
* Revert "Merge pull request #16400 from bogdan/last-with-sql"Sean Griffin2016-02-011-17/+22
| | | | | | | | | | This reverts commit 9f3730a516f30beb0050caea9539f8d6b808e58a, reversing changes made to 2637fb75d82e1c69333855abd58c2470994995d3. There are additional issues with this commit that need to be addressed before this change is ready (see #23377). This is a temporary revert in order for us to have more time to address the issues with that PR, without blocking the release of beta2.
* Reworked ActiveRecord::Relation#last to always use SQLBogdan Gusiev2016-01-281-22/+17
| | | | instead of loading relation
* Merge pull request #23303 from Empact/find-nth-deprecationRafael França2016-01-281-11/+10
|\ | | | | Consistently warn that passing an offset to `find_nth` is deprecated
| * Consistently warn that passing an offset to `find_nth` is deprecatedBen Woosley2016-01-271-11/+10
| | | | | | | | | | | | | | | | | | | | | | | | @bogdan pointed out that a `loaded?` relation would not warn that the supplied offset would be removed. This fixes that oversight. https://github.com/rails/rails/commit/16a476e4f8f802774ae7c8dca2e59f4e672dc591#commitcomment-15706834 Although this second argument is probably not widely used, and would be ignored anyway in the loaded? case, this could protect callers from gotchas. [Ben Woosley & Victor Kmita]
* | 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
* | Use bind parameters for ranges in where clausesSean Griffin2016-01-212-2/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a similar case to wanting ot use bind params for limit and offset. Right now passing a range grows the amount of prepared statements in an unbounded fashion. We could avoid using prepared statements in that case, similar to what we do with arrays, but there's a known number of variants for ranges. This ends up duplicating some of the logic from Arel for how to handle potentially infinite ranges, and that behavior may be removed from Arel in the future. Fixes #23074
* | Changed options for find_each and variants to have options start/finish ↵Vipul A M2016-01-182-47/+32
| | | | | | | | | | | | instead of start_at/end_at based on comments at https://github.com/rails/rails/pull/12257#issuecomment-74688344
* | Properly include the `from` clause when merging relationsSean Griffin2016-01-141-0/+3
| | | | | | | | | | | | | | | | | | | | The code that set the from clause was removed in bdc5141652770fd227455681cde1f9899f55b0b9. I did not give any reason for doing so. My assumption was that I intended to change it to use the clause objects, but forgot. We appeared to not have test coverage for this case. Fixes #22996
* | 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]
* | Revert "Change `WhereClause#merge` to same named columns on diff tables"Sean Griffin2016-01-121-10/+11
| | | | | | | | | | | | | | | | | | This reverts commit 5d41cb3bfd6b19833261622ce5d339b1e580bd8b. This implementation does not properly handle cases involving predicates which are not associated with a bind param. I have the fix in mind, but don't have time to implement just yet. It will be more similar to #22823 than not.
* | Change `WhereClause#merge` to same named columns on diff tablesSean Griffin2016-01-121-11/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While the predicates are an arel equality node where the left side is a full arel attribute, the binds just have the name of the column and nothing else. This means that while splitting the predicates can include the table as a factor, the binds cannot. It's entirely possible that we might be able to have the bind params carry a bit more information (I don't believe the name is used for anything but logging), and that is probably a worthwhile change to make in the future. However the simplest (and likely slightly faster) solution is to simply use the indices of the conflicts in both cases. This means that we only have to compute the collision space once, instead of twice even though we're doing an additional array iteration. Regardless, this method isn't a performance hotspot. Close #22823. [Ben Woosley & Sean Griffin]
* | activerecord: reuse immutable objectsTamir Duberstein2016-01-043-12/+14
| |
* | activerecord: allocate fewer arrays in `RecordFetchWarning`Tamir Duberstein2016-01-041-6/+4
| |
* | Merge pull request #22877 from kamipo/refactor_case_sensitive_comparisonRafael França2016-01-011-0/+1
|\ \ | | | | | | Refactor `case_{sensitive|insensitive}_comparison`
| * | Refactor `case_{sensitive|insensitive}_comparison`Ryuta Kamizono2016-01-011-0/+1
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | Before: ``` SELECT 1 AS one FROM "topics" WHERE "topics"."title" = 'abc' LIMIT $1 [["LIMIT", 1]] ``` After: ``` SELECT 1 AS one FROM "topics" WHERE "topics"."title" = $1 LIMIT $2 [["title", "abc"], ["LIMIT", 1]] ```
* / Improve example of #or to use different column values in the where clausesTim Sandberg2015-12-301-2/+2
|/
* Fix `first(limit)` to take advantage of `loaded?` records if availableBen Woosley2015-12-241-5/+20
| | | | | | | | | | | | | | | | | I realized that `first(2)`, etc. was unnecessarily querying for the records when they were already preloaded. This was because `find_nth_with_limit` can not know which `@records` to return because it conflates the `offset` and `index` into a single variable, while the `@records` only needs the `index` itself to select the proper record. Because `find_nth` and `find_nth_with_limit` are public methods, I instead introduced a private method `find_nth_with_limit_and_offset` which is called internally and handles the `loaded?` checking. Once the `offset` argument is removed from `find_nth`, `find_nth_with_limit_and_offset` can be collapsed into `find_nth_with_limit`, with `offset` always equal to `offset_index`.
* Deprecate passing `offset` to `find_nth`Ben Woosley2015-12-241-8/+16
| | | | | | | | All uses of the `offset` are passing `offset_index`. Better to push down the `offset` consideration into `find_nth`. This also works toward enabling `find_nth_with_limit` to take advantage of the `loaded?` state of the relation.
* Merge pull request #22653 from matthewd/find_array_orderedMatthew Draper2015-12-181-0/+17
|\ | | | | | | ActiveRecord::Base#find(array) returning result in the same order as the array passed
| * Implement limit & offset for ourselvesMatthew Draper2015-12-181-6/+19
| | | | | | | | | | | | | | | | | | | | We know the query will return exactly one row for each entry in the `ids` array, so we can do all the limit/offset calculations on that array, in advance. I also split our new ordered-ids behaviour out of the existing `find_some` method: especially with this change, the conditionals were overwhelming the actual logic.
| * using order_values method instead of relying on ActiveRecord::Relation ↵Miguel Grazziotin2015-06-191-2/+2
| | | | | | | | @values hash
| * WIP: fixing the limit bug and introducing new tests (failing for now) on ↵Miguel Grazziotin2015-06-191-3/+5
| | | | | | | | .find(array) with offset
| * do not change the order of the result if the object was already ordered by ↵Miguel Grazziotin2015-06-051-0/+1
| | | | | | | | the user via :order clause
| * [#20338] improving implementation, fixing and adding some more specsMiguel Grazziotin2015-06-031-5/+2
| |
| * [#20338] WIP: first basic implementation and specsMiguel Grazziotin2015-05-291-1/+5
| |
* | 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 ```
* | Revert "Perform a more efficient query in `Relation#any?`"Sean Griffin2015-12-141-7/+2
| | | | | | | | | | | | | | | | | | This reverts commit 6d5b1fdf55611de2a1071c37544933bb588ae88e. `eager_load` and `references` can include hashes, which won't match up with `references` A test case has been added to demonstrate the problem
* | Perform a more efficient query in `Relation#any?`Sean Griffin2015-12-141-2/+7
| | | | | | | | | | | | | | | | | | | | | | This was changed in 421c81b, as `exists?` blows up if you are eager loading a polymorphic association, as it'll try to construct a join to that table. The previous change decided to execute a `count` instead, which wouldn't join. Of course, the only time we actually need to perform a join on the eager loaded values (which would perform a left outer join) is if they're being referenced in the where clause. This doesn't affect inner joins.
* | 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.
* | Ensure `Relation` responds to `shuffle`Sean Griffin2015-12-011-1/+1
| | | | | | | | | | It appears that I missed this one when I delegated all the non-mutation array methods that were not on Enumerable
* | Docs: ActiveRecord::QueryMethods#joinsJared Beck2015-11-251-2/+22
| | | | | | | | [ci skip]
* | Merge pull request #21000 from twalpole/find_or_parameter_issuesSean Griffin2015-11-231-0/+4
|\ \ | | | | | | Update and fix forbidden attributes test issues caused by AC::Parameters change
| * | Update and fix forbidden attributes testsThomas Walpole2015-11-031-0/+4
| | | | | | | | | | | | Add AC::Parameters tests for WhereChain#not
* | | Remove blanket array delegation from `Relation`Sean Griffin2015-11-231-14/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | As was pointed out by #17128, our blacklist of mutation methods was non-exhaustive (and would need to be kept up to date with each new version of Ruby). Now that `Relation` includes `Enumerable`, the number of methods that we actually need to delegate are pretty small. As such, we can change to explicitly delegating the few non-mutation related methods that `Array` has which aren't on `Enumerable`
* | | Raise ArgumentError when passing a truthy value to mergeAndrew White2015-11-171-1/+3
| | | | | | | | | | | | | | | | | | In b71e08f we started raising when nil or false was passed to merge to fix #12264, however we should also do this for truthy values that are invalid like true.
* | | Make `AR::SpawnMethods#merge!` to check an arg is a Procyui-knk2015-11-121-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | From Ruby ( 2.3.0dev trunk 52520), `Hash#to_proc` is defined (https://github.com/ruby/ruby/commit/fbe967ec02cb65a7efa3fb8f3d747cf6f620dde1), and many tests have been failed with `ArgumentError: wrong number of arguments (given 0, expected 1)`. Because we call `Hash#to_proc` with no args in `#merge!`. This commit changes order of conditionals to not call `Hash#to_proc`.
* | | docs, get rid of artifact in `RecordFetchWarning` docs.Yves Senn2015-11-071-0/+2
|/ / | | | | | | | | | | | | [ci skip] There was a `ActiveRecord::Relation::RecordFetchWarning::ActiveSupport` artifact caused by subscribing to AS notifications.
* | 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
| | | |
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-05 12:54:42 +0000