aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/lib/active_record/relation
Commit message (Collapse)AuthorAgeFilesLines
...
* | Move `where_values_hash` over to `WhereClause`Sean Griffin2015-01-251-0/+22
| |
* | Move `where_unscoping` logic over to `WhereClause`Sean Griffin2015-01-252-17/+25
| |
* | Remove most references to `where_values` in `QueryMethods`Sean Griffin2015-01-251-2/+2
| | | | | | | | | | We're still using it in `where_unscoping`, which will require moving additional logic.
* | `Relation#Merger` can merge all clause methodsSean Griffin2015-01-251-3/+11
| | | | | | | | This will make it easy to add `having_clause` and `join_clause` later.
* | Rename `WhereClause#parts` to `WhereClause#predicates`Sean Griffin2015-01-252-16/+16
| |
* | Move `where.not` logic into `WhereClause`Sean Griffin2015-01-252-15/+25
| |
* | Move the construction of `WhereClause` objects out of `Relation`Sean Griffin2015-01-252-14/+42
| | | | | | | | | | Yes, I know, I called it a factory so I'm basically the worst person ever who loves Java and worships the Gang of Four.
* | Remove all references to `where_values` in association codeSean Griffin2015-01-251-0/+2
| |
* | Remove references to `:bind` in `except`Sean Griffin2015-01-251-3/+0
| | | | | | | | Bind values are no longer a thing, so this is unnecessary.
* | Move where merging logic over to `WhereClause`Sean Griffin2015-01-252-40/+37
| | | | | | | | | | | | 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-252-0/+63
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* | Expand the number of types which can use prepared statementsSean Griffin2015-01-242-6/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This will allow all types which require no additional handling to use prepared statements. Specifically, this will allow for `true`, `false`, `Date`, `Time`, and any custom PG type to use prepared statements. This also revealed another source of nil columns in bind params, and an inconsistency in their use. The specific inconsistency comes from a nested query coming from a through association, where one of the inversed associations is not bi-directional. The stop-gap is to simply construct the column at the site it is being used. This should simply go away on its own once we use `Attribute` to represent them instead, since we already have all of the information we need.
* | Don't mutate `where_values`Sean Griffin2015-01-241-1/+1
| | | | | | | | | | | | | | | | This is to help facilitate future refactorings, as the internal representation is changed. I'm planning on having `where_values` return an array that's computed on call, which means that mutation will have no affect. This is the only remaining place that was mutating (tested by replacing the method with calling `dup`)
* | Don't rely on relation mutability when building through associationsSean Griffin2015-01-241-18/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Specifically, the issue is relying on `where_unscoping` mutating the where values. It does not, however, mutate the bind values, which could cause an error under certain circumstances. This was not exposed by the tests, since the only place which would have been affected is unscoping a boolean, which doesn't go through prepared statements. I had a hard time getting better test coverage to demonstrate the issue. This in turn, caused `merge` to go through proper logic, and try to clear out the binds associated with the unscoped relation, which then exposed a source of `nil` for the columns, as binds weren't expanding `{ "posts.id" => 1 }` to `{ "posts" => { "id" => 1 } }`. This has been fixed. The bulk of `create_binds` needed to be moved to a separate method, since the dot notation should not be expanded recursively. I'm pretty sure this removes a subtle quirk that a ton of code in `Relation::Merger` is working around, and I suspect that code can be greatly simplified. However, unraveling that rats nest is no small task.
* | Don't duplicate `Relation::VALUE_METHODS` in `Relation::Merger`Sean Griffin2015-01-241-2/+1
| |
* | Don't remove join dependencies in `Relation#exists?`Sean Griffin2015-01-231-1/+1
| | | | | | | | Fixes #18632
* | Fix bind value copying from subqueried relationsSean Griffin2015-01-192-13/+2
| | | | | | | | | | | | | | | | | | | | | | 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)
* | Move `create_binds` over to the `PredicateBuilder`Sean Griffin2015-01-192-34/+25
| | | | | | | | | | | | I'm looking to introduce a `WhereClause` class to handle most of this logic, and this method will eventually move over to there. However, this intermediate refactoring should make that easier to do.
* | Whether a column exists or not doesn't affect whether we can use bindsSean Griffin2015-01-191-6/+3
| | | | | | | | | | | | 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.
* | Don't mutate bind values in `Relation`Sean Griffin2015-01-191-1/+1
| | | | | | | | | | | | | | In order to better facilitate refactoring, most places that mutated `bind_values` have already been removed. One last spot snuck through. Since we're no longer mutating the array, it also does not need to be duped in `initialize_copy`.
* | Properly copy nested bind values from subqueried relationsSean Griffin2015-01-091-3/+1
| | | | | | | | | | | | | | | | | | | | | | 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
* | Correctly fetch bind_values from join in subquerybrainopia2015-01-061-1/+3
| |
* | remove deprecation warning when modifying a Relation with cached arel.Yves Senn2015-01-051-21/+14
| | | | | | | | This adresses https://github.com/rails/rails/commit/1b7aa62b184c4410c99208f71b59bbac5c5f03be#commitcomment-9147803
* | Remove unneeded `require 'as/deprecation'`claudiob2015-01-041-1/+0
| | | | | | | | | | Tests should still pass after removing `require 'active_support/deprecation'` from these files since the related deprecations have been removed.
* | Remove unneeded requiresRafael Mendonça França2015-01-041-2/+0
| | | | | | | | These requires were added only to change deprecation message
* | Remove support to activerecord-deprecated_findersRafael Mendonça França2015-01-021-25/+12
| |
* | Remove all cases of manuallly wrapping `Arel::Nodes::Quoted`Sean Griffin2014-12-291-19/+4
| | | | | | | | | | | | | | | | | | | | 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.
* | Rely on the injectable type caster for `arel_table`Sean Griffin2014-12-294-24/+2
| | | | | | | | | | | | | | This API will require much less consuming code to change to accomodate the removal of automatic type casting from Arel. As long as the predicates are constructed using the `arel_table` off of an AR subclass, there will be no changes that need to happen.
* | Inform Arel we don't need additional type casting in batchesSean Griffin2014-12-261-1/+6
| | | | | | | | | | | | | | 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
* | Inform Arel that we don't need additional type casting in batchingSean Griffin2014-12-261-2/+8
| | | | | | | | | | | | | | 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
* | Go through normal where logic in `apply_join_dependency`Sean Griffin2014-12-261-1/+1
| | | | | | | | Part of the larger refactoring to remove type casting from Arel.
* | We don't need to type cast the offset in `find_in_batches`Sean Griffin2014-12-261-1/+5
| | | | | | | | | | | | | | 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-1/+6
| | | | | | | | | | | | | | | | Part of a larger refactoring to remove type casting from Arel. /cc @mrgilman [Sean Griffin & Melanie Gilman]
* | Eagerly cast range values in the predicate builderSean Griffin2014-12-262-1/+25
| | | | | | | | | | | | | | | | | | A custom object is required for this, as you cannot build a range object out of `Arel::Nodes::Quoted` objects. Depends on the changes introduced in https://github.com/rails/arel/commit/cf03bd45e39def057a2f63e42a3391b7d750dece /cc @mrgilman
* | Perform casting of single values within the predicate builderSean Griffin2014-12-264-6/+31
| | | | | | | | | | | | | | | | | | | | | | 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]
* | Remove `klass` and `arel_table` as a dependency of `PredicateBuilder`Sean Griffin2014-12-262-26/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This class cares far too much about the internals of other parts of Active Record. This is an attempt to break out a meaningful object which represents the needs of the predicate builder. I'm not fully satisfied with the name, but the general concept is an object which represents a table, the associations to/from that table, and the types associated with it. Many of these exist at the `ActiveRecord::Base` class level, not as properties of the table itself, hence the need for another object. Currently it provides these by holding a reference to the class, but that will likely change in the future. This allows the predicate builder to remain wholy concerned with building predicates. /cc @mrgilman
* | Refactor association handling in `PredicateBuilder`Sean Griffin2014-12-262-21/+61
| | | | | | | | | | | | | | | | | | | | I'm attempting to remove `klass` as a dependency of the predicate builder, in favor of an object that better represents what we're using it for. The only part of this which doesn't fit nicely into that picture is the check for an association being polymorphic. Since I'm not yet sure what that is going to look like, I've moved this logic into another class in an attempt to separate things that will change from things that won't.
* | Re-use the predicate builder in the `ArrayHandler`Sean Griffin2014-12-262-8/+16
| | | | | | | | | | | | | | | | | | | | This reduces the number of places which will need to care about single value or range specific logic as we introduce type casting. The array handler is only responsible for producing `in` statements. /cc @mrgilman [Sean Griffin & Melanie Gilman]
* | Change `PredicateBuilder` handler methods to instance methodsSean Griffin2014-12-265-30/+71
| | | | | | | | | | | | | | | | | | | | | | | | 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]
* | Add missing `:nodoc:`Sean Griffin2014-12-261-1/+1
| | | | | | | | | | We're accidentally documenting `PredicateBuilder` and `ArrayHandler` since there's a constant which is missing `# :nodoc:`
* | Inject the `PredicateBuilder` into the `Relation` instanceSean Griffin2014-12-262-2/+2
| | | | | | | | | | | | | | 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
* | Clarity start parameterMichael Dawson2014-12-191-2/+2
| | | | | | | | | | | | I find that `Specifies the starting point for the batch processing.` does not give enough information for me to understand what this parameter actually does.
* | Fix ProtocolViolation/bind message supplies for polymorphic + pluck or groupMiklos Fazkeas2014-12-111-2/+2
| |
* | Remove deprecated behavior allowing nested arrays as query valuesMelanie Gilman2014-12-041-10/+0
| |
* | Deprecate `Class` handler in `PredicateBuilder`Melanie Gilman2014-12-041-3/+9
| | | | | | | | Users should pass strings to queries instead of classes
* | Clarify that batching methods can be used with any orderable type primary ↵Isaac Seymour2014-12-031-4/+4
| | | | | | | | key, not just integer ones, as per @a58cafeb3a86be46849de57481b6644094fb8165
* | Refactor `build_from_hash` to convert dot notation to hash firstMelanie Gilman2014-12-021-29/+34
| | | | | | | | | | | | | | | | | | | | This ensures that we're handling all forms of nested tables the same way. We're aware that the `convert_dot_notation_to_hash` method will cause a performance hit, and we intend to come back to it once we've refactored some of the surrounding code. [Melissa Xie & Melanie Gilman]
* | Merge pull request #17886 from mrgilman/refactor-predicate-builderSean Griffin2014-12-022-16/+24
|\ \ | | | | | | Refactor `PredicateBuilder` from singleton to instance
| * | Refactor `PredicateBuilder` from singleton to instanceMelanie Gilman2014-12-022-16/+24
| | |
* | | Allow to unscope where conditions using `arel_table` with Symboldeeeki2014-12-031-1/+1
|/ / | | | | | | | | | | This commit fixes the following case. User.where(User.arel_table[:created_at].lteq(1.year.ago)).unscope(where :created_at)
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-24 05:19:02 +0000