aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/test/cases/relation
Commit message (Collapse)AuthorAgeFilesLines
...
* Add three new rubocop rulesRafael Mendonça França2016-08-163-4/+4
| | | | | | | | Style/SpaceBeforeBlockBraces Style/SpaceInsideBlockBraces Style/SpaceInsideHashLiteralBraces Fix all violations in the repository.
* Use `ActiveRecord::TestCase` rather than `ActiveSupport::TestCase` in AR ↵Ryuta Kamizono2016-08-111-1/+1
| | | | test cases
* Add `Style/EmptyLines` in `.rubocop.yml` and remove extra empty linesRyuta Kamizono2016-08-071-1/+0
|
* normalizes indentation and whitespace across the projectXavier Noria2016-08-062-10/+10
|
* modernizes hash syntax in activerecordXavier Noria2016-08-063-17/+17
|
* applies new string literal convention in activerecord/testXavier Noria2016-08-069-121/+121
| | | | | The current code base is not uniform. After some discussion, we have chosen to go with double quotes by default.
* No need `public_send`Ryuta Kamizono2016-07-171-2/+2
|
* Add missing test case for record_fetched_greater_than configPrathamesh Sonpatki2016-04-111-11/+23
| | | | - The negative scenario test case was missing earlier.
* Merge pull request #22365 from ↵Sean Griffin2016-02-171-1/+13
|\ | | | | | | | | phuibonhoa/phuibonhoa/polymorphic_where_multiple_types Fixed `where` for polymorphic associations when passed an array containing different types.
| * Fixed `where` for polymorphic associations when passed an array containing ↵Philippe Huibonhoa2016-02-161-1/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | different types. When passing in an array of different types of objects to `where`, it would only take into account the class of the first object in the array. PriceEstimate.where(estimate_of: [Treasure.find(1), Car.find(2)]) # => SELECT "price_estimates".* FROM "price_estimates" WHERE ("price_estimates"."estimate_of_type" = 'Treasure' AND "price_estimates"."estimate_of_id" IN (1, 2)) This is fixed to properly look for any records matching both type and id: PriceEstimate.where(estimate_of: [Treasure.find(1), Car.find(2)]) # => SELECT "price_estimates".* FROM "price_estimates" WHERE (("price_estimates"."estimate_of_type" = 'Treasure' AND "price_estimates"."estimate_of_id" = 1) OR ("price_estimates"."estimate_of_type" = 'Car' AND "price_estimates"."estimate_of_id" = 2))
* | Show proper error message when a non-relation object is passed to ↵Prathamesh Sonpatki2016-02-171-0/+6
|/ | | | | | | | | | | | | | AR::Relation#or - Previously it used to show error message <"undefined method `limit_value' for {:title=>\"Rails\"}:Hash"> - Now it shows following error message. >> Post.where.not(name: 'DHH').or(name: 'Tenderlove') ArgumentError: You have passed Hash object to #or. Pass an ActiveRecord::Relation object instead. - Fixes #23714.
* Typos in AR testsAkira Matsuda2016-02-041-2/+2
|
* Defer Arel attribute lookup to the model classMatthew Draper2016-02-041-0/+4
| | | | | 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.
* Properly include the `from` clause when merging relationsSean Griffin2016-01-141-0/+7
| | | | | | | | | | 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-1/+3
| | | | | | | | 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-15/+2
| | | | | | | | | 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-2/+15
| | | | | | | | | | | | | | | | | | | | 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]
* 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
* Remove blanket array delegation from `Relation`Sean Griffin2015-11-231-6/+0
| | | | | | | | | 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`
* Define `sanitize_sql_for_order` for AR and use it inside `preprocess_order_args`yui-knk2015-11-021-0/+4
| | | | This commit follows up of 6a6dbb4c51fb0c58ba1a810eaa552774167b758a.
* Alias left_joins to left_outer_joinsTakashi Kokubun2015-10-311-1/+1
|
* Suppress warnings of `assigned but unused variable`yui-knk2015-10-171-2/+0
|
* `where` raises ArgumentError on unsupported types.Jake Worth2015-10-161-0/+6
| | | | [#20473]
* Fix AC::Parameters not being sanitized for query methods.Guo Xiang Tan2015-10-021-0/+26
|
* Removed mocha from Active Record Part 2Ronak Jangir2015-09-161-3/+4
|
* Add test to 57daaefRafael Mendonça França2015-05-281-1/+1
|
* Remove unused variableArun Agrawal2015-05-261-1/+1
| | | | Was left in adfab2dcf4003ca564d78d4425566dd2d9cd8b4f
* deprecate `Relation#uniq` use `Relation#distinct` instead.Yves Senn2015-05-261-4/+13
| | | | | | | | | 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.
* Add `config.active_record.warn_on_records_fetched_greater_than` optionJason Nochlin2015-03-251-0/+28
| | | | | | | | | When set to an integer, a warning will be logged whenever a result set larger than the specified size is returned by a query. Fixes #16463 The warning is outputed a module which is prepended in an initializer, so there will be no performance impact if `config.active_record.warn_on_records_fetched_greater_than` is not set.
* Respect custom primary keys for associations in `Relation#where`Sean Griffin2015-02-041-1/+37
| | | | | | | | | | While we query the proper columns, we go through normal handling for converting the value to a primitive which assumes it should use the table's primary key. If the association specifies a different value (and we know that we're working with an association), we should use the custom primary key instead. Fixes #18813.
* Post.all.or(anything) == Post.allSean Griffin2015-01-292-5/+5
|
* Bring the implementation of Relation#or up to speedSean Griffin2015-01-282-3/+26
|
* Added #or to ActiveRecord::RelationMatthew Draper2015-01-281-0/+81
| | | | | | | 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-2/+2
| | | | | | | | `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-272-19/+8
| | | | | | | | | | | 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.
* `WhereClause#predicates` does not need to be publicSean Griffin2015-01-272-102/+27
| | | | | | | | | | | The only place it was accessed was in tests. Many of them have another way that they can test their behavior, that doesn't involve reaching into internals as far as they did. `AssociationScopeTest` is testing a situation where the where clause would have one bind param per predicate, so it can just ignore the predicates entirely. The where chain test was primarly duplicating the logic tested on `WhereClause` directly, so I instead just make sure it calls the appropriate method which is fully tested in isolation.
* Move where grouping into `WhereClause`Sean Griffin2015-01-271-0/+33
|
* Move the `from` bind logic to a `FromClause` classSean Griffin2015-01-261-3/+3
| | | | | | | 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-1/+1
| | | | | | | | | | 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 all references to `where_values` in testsSean Griffin2015-01-252-39/+39
|
* Move `where_unscoping` logic over to `WhereClause`Sean Griffin2015-01-251-0/+14
|
* Move `where.not` logic into `WhereClause`Sean Griffin2015-01-251-0/+26
|
* Remove all references to `where_values` in association codeSean Griffin2015-01-251-0/+5
|
* Move where merging logic over to `WhereClause`Sean Griffin2015-01-251-0/+42
| | | | | | This object being a black box, it knows the details of how to merge itself with another where clause. This removes all references to where values or bind values in `Relation::Merger`
* Introduce `Relation::WhereClause`Sean Griffin2015-01-251-0/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The way that bind values are currently stored on Relation is a mess. They can come from `having`, `where`, or `join`. I'm almost certain that `having` is actually broken, and calling `where` followed by `having` followed by `where` will completely scramble the binds. Joins don't actually add the bind parameters to the relation itself, but instead add it onto an accessor on the arel AST which is undocumented, and unused in Arel itself. This means that the bind values must always be accessed as `relation.arel.bind_values + relation.bind_values`. Anything that doesn't is likely broken (and tons of bugs have come up for exactly that reason) The result is that everything dealing with `Relation` instances has to know far too much about the internals. The binds are split, combined, and re-stored in non-obvious ways that makes it difficult to change anything about the internal representation of `bind_values`, and is extremely prone to bugs. So the goal is to move a lot of logic off of `Relation`, and into separate objects. This is not the same as what is currently done with `JoinDependency`, as `Relation` knows far too much about its internals, and vice versa. Instead these objects need to be black boxes that can have their implementations swapped easily. The end result will be two classes, `WhereClause` and `JoinClause` (`having` will just re-use `WhereClause`), and there will be a single method to access the bind values of a `Relation` which will be implemented as ``` join_clause.binds + where_clause.binds + having_clause.binds ``` This is the first step towards that refactoring, with the internal representation of where changed, and an intermediate representation of `where_values` and `bind_values` to let the refactoring take small steps. These will be removed shortly.
* Fix bind value copying from subqueried relationsSean Griffin2015-01-191-0/+8
| | | | | | | | | | | With the old implementation, the bind values were created, and then we search the attributes for `Relation` objects, and merge them. This completely ignores the order that the actual `where` clause will use. If all non-relation where parameters are before the relations, it will work. However, if we query on both a relation and a value, with the value coming second, it breaks. The order of the hash should not affect the final query (especially since hashes being ordered is an implementation detail)
* Whether a column exists or not doesn't affect whether we can use bindsSean Griffin2015-01-191-1/+1
| | | | | | Looking through the blame, this logic used to be when we actually created the bind tuple. My guess is that `nil` couldn't be handled there at that time. It can, now.
* Should escape regexp wildcard character `.`Ryuta Kamizono2015-01-191-1/+1
| | | | | `.` is regexp meta character. It should be escape for `assert_match` correctly.
* Properly copy nested bind values from subqueried relationsSean Griffin2015-01-091-9/+21
| | | | | | | | | | | This is cropping up all over the place. After a brief dive, I'm really not sure why we have `arel.bind_values` at all. A cursory grep didn't reveal where they're actually being assigned (it's definitely in AR, not in Arel). I'd like to dig further into it, as I'm fairly certain we don't actually need it, we just need a way for the predicate builder to communicate merged binds upstream. Fixes #18414
* Remove all cases of manuallly wrapping `Arel::Nodes::Quoted`Sean Griffin2014-12-291-2/+2
| | | | | | | | | | This is no longer required now that we are injecting a type caster object into the Arel table, with the exception of uniqueness validations. Since it calls `ConnectionAdapter#type_cast`, the value has already been cast for the database. We don't want Arel to attempt to cast it further, so we need to continue wrapping it in a quoted node. This can potentially go away when this validator is refactored to make better use of `where` or the predicate builder.
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-02 13:28:37 +0000