aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/lib/active_record/relation
Commit message (Collapse)AuthorAgeFilesLines
* 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)
* Update Arel usage for rails/arel#98fc259Sean Griffin2014-11-292-5/+5
| | | | | `where_sql` now requires that we pass it an engine. None of the manager classes take an engine in their constructor.
* Stop using `Arel::Table.engine`Sean Griffin2014-11-292-3/+3
| | | | | | | | | | | | | We never actually make use of it on the table, since we're constructing the select manager manually. It looks like if we ever actually were grabbing it from the table, we're grossly misusing it since it's meant to vary by AR class. Its existence on `Arel::Table` appears to be purely for convenience methods that are never used outside of tests. However, in production code it just complicates construction of the tables on the rails side, and the plan is to remove it from `Arel::Table` entirely. I'm not convinced it needs to live on `SelectManager`, etc either.
* Pass symbol as an argument instead of a blockErik Michaels-Ober2014-11-291-1/+1
|
* Fix includes on association with a scope containing joins along with conditionssiddharth@vinsol.com2014-11-211-4/+2
| | | | on the joined assoiciation
* PERF: avoid string allocationsSam2014-11-201-1/+6
|
* Remove the unused second argument to `substitute_at`Sean Griffin2014-11-171-12/+0
| | | | Oh hey, we got to remove some code because of that!
* rm `reorder_bind_params`Sean Griffin2014-11-171-10/+0
| | | | | | Arel handles this for us automatically. Updated tests, as BindParam is no longer a subclass of SqlLiteral. We should remove the second argument to substitute_at entirely, as it's no longer used
* Handle `RangeError` from casting in `find_by` and `find_by!` on RelationSean Griffin2014-11-021-0/+4
| | | | | We should not behave differently just because a class has a default scope.
* Pass the `SelectManager`, rather than the AST when querying w/ RelationSean Griffin2014-11-021-1/+1
| | | | | | Arel specifically handles `SelectManager`, with the same logic we're currently performing. The AST is `Enumerable`, which Arel looks for separately now.
* Don't duplicate predicate building logic in Relation findersSean Griffin2014-11-011-5/+2
|
* Use a bound parameter for the "id = " portion of update statementsSean Griffin2014-11-011-3/+6
| | | | | | We need to re-order the bind parameters since the AST returned by the relation will have the where statement as the first bp, which breaks on PG.
* Correctly cast calculation results on PGSean Griffin2014-11-011-1/+2
| | | | | MySQL reports the column name as `"MAX(developer_id)"`. PG will report it as `"max"`
* [ci skip] `Relation#bind` is not public APISean Griffin2014-11-011-1/+1
|
* Use bind values for joined tables in where statementsSean Griffin2014-11-011-0/+17
| | | | | | | | | | | | | | | In practical terms, this allows serialized columns and tz aware columns to be used in wheres that go through joins, where they previously would not behave correctly. Internally, this removes 1/3 of the cases where we rely on Arel to perform type casting for us. There were two non-obvious changes required for this. `update_all` on relation was merging its bind values with arel's in the wrong order. Additionally, through associations were assuming there would be no bind parameters in the preloader (presumably because the where would always be part of a join) [Melanie Gilman & Sean Griffin]
* Remove redundant substitute index when constructing bind valuesMelanie Gilman2014-10-311-5/+4
| | | | | | We end up re-ordering them either way when we construct the Arel AST (in order to deal with rewhere, etc), so we shouldn't bother giving it a number in the first place beforehand.
* Treat strings greater than int max value as out of rangeSean Griffin2014-10-311-0/+2
| | | | | | | | | | | Sufficiently large integers cause `find` and `find_by` to raise `StatementInvalid` instead of `RecordNotFound` or just returning `nil`. Given that we can't cast to `nil` for `Integer` like we would with junk data for other types, we raise a `RangeError` instead, and rescue in places where it would be highly unexpected to get an exception from casting. Fixes #17380
* Don't require calculations to be aliased to a columnSean Griffin2014-10-311-1/+1
| | | | | | | Arel has changed so that `.sum` no longer aliases `SUM(the_column)` to `sum_id`. This means the type returned by the adapter will be at the key `"SUM(the_column)"`. Longer term, we should eventually be able to retain type information from the AR::Base subclasses used in joined queries
* Use `#between`, rather than `#in` for passing Ranges to ArelSean Griffin2014-10-302-2/+2
| | | | Passing ranges to `#in` has been deprecated in Arel.
* Merge pull request #17421 from rails/warn-with-heredocXavier Noria2014-10-283-9/+22
|\ | | | | let warn with heredocs
| * let's warn with heredocsXavier Noria2014-10-283-9/+22
| | | | | | | | | | | | | | | | | | | | | | | | The current style for warning messages without newlines uses concatenation of string literals with manual trailing spaces where needed. Heredocs have better readability, and with `squish` we can still produce a single line. This is a similar use case to the one that motivated defining `strip_heredoc`, heredocs are super clean.
* | Remove unneccessary default values from relation mergerSean Griffin2014-10-281-2/+2
| | | | | | | | The value methods will default to an empty array for us automatically
* | Call value methods when merging relations, rather than accessing keysSean Griffin2014-10-281-14/+14
|/ | | | | | | | The change to accessing keys directly was originally added to allow `merge` to take a hash. The implementation of `HashMerger` no longer requires us to be doing so. Accessing the values directly makes it impossible to change internal storage details, even if shim methods are added temporarily
* Allow Relation#rewhere to work with infinite range valuesDan Olson2014-10-271-1/+1
|
* Fix Relation.rewhere to work with Range valuesDan Olson2014-10-201-1/+1
|
* [ci skip] Make merge method nodocAnshul Sharma2014-10-201-8/+1
|
* [ci skip] merge docsAnshul Sharma2014-10-201-0/+7
|
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-23 13:38:46 +0000