aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/test/cases/relation
Commit message (Collapse)AuthorAgeFilesLines
* 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.
* Fix failing testsSean Griffin2014-12-291-8/+4
|
* Inform Arel we don't need additional type casting in testsSean Griffin2014-12-262-3/+3
| | | | | | | Part of the larger refactoring to remove type casting from Arel. We can inform it that we already have the right type by wrapping the value in an `Arel::Nodes::Quoted`. This commit can be reverted when we have removed type casting from Arel in Rail 5.1
* Eagerly cast array values passed to the predicate builderSean Griffin2014-12-261-2/+6
| | | | | | | | Part of a larger refactoring to remove type casting from Arel. /cc @mrgilman [Sean Griffin & Melanie Gilman]
* Perform casting of single values within the predicate builderSean Griffin2014-12-261-1/+1
| | | | | | | | | | | As part of the larger refactoring to remove type casting from Arel, we need to do the casting of values eagerly. The predicate builder is the closest place that knows about the Active Record class, and can therefore have the type information. /cc @mrgilman [Sean Griffin & Melanie Gilman]
* Fix new warning in ruby 2.2Sean Griffin2014-12-261-2/+2
|
* Change `PredicateBuilder` handler methods to instance methodsSean Griffin2014-12-261-1/+3
| | | | | | | | | | | | This will allow us to pass the predicate builder into the constructor of these handlers. The procs had to be changed to objects, because the `PredicateBuilder` needs to be marshalable. If we ever decide to make `register_handler` part of the public API, we should come up with a better solution which allows procs. /cc @mrgilman [Sean Griffin & Melanie Gilman]
* Inject the `PredicateBuilder` into the `Relation` instanceSean Griffin2014-12-261-1/+1
| | | | | | | Construction of relations can be a hotspot, we don't want to create one of these in the constructor. This also allows us to do more expensive things in the predicate builder's constructor, since it's created once per AR::Base subclass
* Remove deprecated behavior allowing nested arrays as query valuesMelanie Gilman2014-12-041-6/+0
|
* Build fix when running in isolationArun Agrawal2014-11-141-0/+1
| | | | | `Computer` class needs to be require See #17217 for more details
* Fix test which failed in isolationSean Griffin2014-11-011-0/+1
| | | | It was transitively relying on the vertex model being loaded
* Allow Relation#rewhere to work with infinite range valuesDan Olson2014-10-271-0/+21
|
* Fix Relation.rewhere to work with Range valuesDan Olson2014-10-201-0/+7
|
* A `NullRelation` should represent nothing. Closes #15176.Yves Senn2014-09-111-0/+4
| | | | | | [Matthew Draper & Yves Senn] Closes #16860. (pull request to discuss the implementation)
* Fix query with nested array in Active RecordCristian Bica2014-09-061-1/+3
| | | | | | | | `User.where(id: [[1,2],3])` was equal to `User.where(id:[1, 2, 3])` in Rails 4.1.x but because of some refactoring in Arel this stopped working in 4.2.0. This fixes it in Rails. [Dan Olson & Cristian Bica]
* Load :developers fixtures where expecting a Developer to be thereAkira Matsuda2014-09-051-1/+1
|
* "warning: assigned but unused variable"Akira Matsuda2014-08-211-1/+1
|
* Only merge scopes with zero arity in has_many throughAgis-2014-08-201-0/+13
| | | | | | | | | | | | | | | with dynamic conditions. Fixes #16128 This bug was introduced in https://github.com/rails/rails/commit/c35e438620f2d56562251571377995359546393d so it's present from 4.1.2-rc1 and after. https://github.com/rails/rails/commit/c35e438620f2d56562251571377995359546393d merges any relation scopes passed as proc objects to the relation, but does *not* take into account the arity of the lambda. To reproduce: https://gist.github.com/Agis-/5f1f0d664d2cd08dfb9b
* Add a test case of nested empty array values in conditionsJean Boussier2014-08-171-0/+4
| | | | | | | | | | | | Post.where(id: [[]]).to_a Used to fail with a SQL syntax error (until 4.1): SELECT ... WHERE id in (); It now properly generate: SELECT ... WHERE 1=0;
* Fixed AR::Relation#where edge case with Hash and other RelationBogdan Gusiev2014-08-141-0/+9
| | | | | | Example: Author.where(posts: { author_id: Author.where(country_id: 1) }).joins(:posts)
generated by cgit v1.2.3 (git 2.25.1) at 2024-11-01 16:34:51 +0000