- 27 12月, 2014 6 次提交
-
-
由 Sean Griffin 提交于
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
-
由 Sean Griffin 提交于
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.
-
由 Sean Griffin 提交于
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]
-
由 Sean Griffin 提交于
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]
-
由 Sean Griffin 提交于
We're accidentally documenting `PredicateBuilder` and `ArrayHandler` since there's a constant which is missing `# :nodoc:`
-
由 Sean Griffin 提交于
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
-
- 19 12月, 2014 1 次提交
-
-
由 Michael Dawson 提交于
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.
-
- 11 12月, 2014 1 次提交
-
-
由 Miklos Fazkeas 提交于
-
- 05 12月, 2014 2 次提交
-
-
由 Melanie Gilman 提交于
-
由 Melanie Gilman 提交于
Users should pass strings to queries instead of classes
-
- 04 12月, 2014 1 次提交
-
-
由 Isaac Seymour 提交于
Clarify that batching methods can be used with any orderable type primary key, not just integer ones, as per @a58cafeb
-
- 03 12月, 2014 2 次提交
-
-
由 Melanie Gilman 提交于
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]
-
由 Melanie Gilman 提交于
-
- 02 12月, 2014 1 次提交
-
-
由 deeeki 提交于
This commit fixes the following case. User.where(User.arel_table[:created_at].lteq(1.year.ago)).unscope(where :created_at)
-
- 30 11月, 2014 2 次提交
-
-
由 Sean Griffin 提交于
`where_sql` now requires that we pass it an engine. None of the manager classes take an engine in their constructor.
-
由 Sean Griffin 提交于
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.
-
- 29 11月, 2014 1 次提交
-
-
由 Erik Michaels-Ober 提交于
-
- 21 11月, 2014 1 次提交
-
-
由 siddharth@vinsol.com 提交于
on the joined assoiciation
-
- 20 11月, 2014 1 次提交
-
-
由 Sam 提交于
-
- 18 11月, 2014 2 次提交
-
-
由 Sean Griffin 提交于
Oh hey, we got to remove some code because of that!
-
由 Sean Griffin 提交于
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
-
- 03 11月, 2014 2 次提交
-
-
由 Sean Griffin 提交于
We should not behave differently just because a class has a default scope.
-
由 Sean Griffin 提交于
Arel specifically handles `SelectManager`, with the same logic we're currently performing. The AST is `Enumerable`, which Arel looks for separately now.
-
- 02 11月, 2014 5 次提交
-
-
由 Sean Griffin 提交于
-
由 Sean Griffin 提交于
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.
-
由 Sean Griffin 提交于
MySQL reports the column name as `"MAX(developer_id)"`. PG will report it as `"max"`
-
由 Sean Griffin 提交于
-
由 Sean Griffin 提交于
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]
-
- 01 11月, 2014 2 次提交
-
-
由 Melanie Gilman 提交于
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.
-
由 Sean Griffin 提交于
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
-
- 31 10月, 2014 1 次提交
-
-
由 Sean Griffin 提交于
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
-
- 30 10月, 2014 1 次提交
-
-
由 Sean Griffin 提交于
Passing ranges to `#in` has been deprecated in Arel.
-
- 29 10月, 2014 3 次提交
-
-
由 Xavier Noria 提交于
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.
-
由 Sean Griffin 提交于
The value methods will default to an empty array for us automatically
-
由 Sean Griffin 提交于
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
-
- 27 10月, 2014 1 次提交
-
-
由 Dan Olson 提交于
-
- 20 10月, 2014 3 次提交
-
-
由 Dan Olson 提交于
-
由 Anshul Sharma 提交于
-
由 Anshul Sharma 提交于
-
- 14 10月, 2014 1 次提交
-
-
由 claudiob 提交于
This commit removes the duplication of the error message: > Couldn't find #{@klass.name} with [#{arel.where_sql}] introduced in #15791 by adding a private method `find_nth!` that deals with all the method like `first!` and `second!`.
-