- 25 1月, 2015 4 次提交
-
-
由 Sean Griffin 提交于
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.
-
由 Sean Griffin 提交于
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`)
-
由 Sean Griffin 提交于
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.
-
由 Sean Griffin 提交于
-
- 24 1月, 2015 1 次提交
-
-
由 Sean Griffin 提交于
Fixes #18632
-
- 20 1月, 2015 4 次提交
-
-
由 Sean Griffin 提交于
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)
-
由 Sean Griffin 提交于
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.
-
由 Sean Griffin 提交于
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.
-
由 Sean Griffin 提交于
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`.
-
- 10 1月, 2015 1 次提交
-
-
由 Sean Griffin 提交于
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
-
- 06 1月, 2015 1 次提交
-
-
由 brainopia 提交于
-
- 05 1月, 2015 1 次提交
- 04 1月, 2015 2 次提交
-
-
由 claudiob 提交于
Tests should still pass after removing `require 'active_support/deprecation'` from these files since the related deprecations have been removed.
-
由 Rafael Mendonça França 提交于
These requires were added only to change deprecation message
-
- 02 1月, 2015 1 次提交
-
-
由 Rafael Mendonça França 提交于
-
- 30 12月, 2014 2 次提交
-
-
由 Sean Griffin 提交于
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.
-
由 Sean Griffin 提交于
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.
-
- 27 12月, 2014 13 次提交
-
-
由 Sean Griffin 提交于
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
-
由 Sean Griffin 提交于
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
-
由 Sean Griffin 提交于
Part of the larger refactoring to remove type casting from Arel.
-
由 Sean Griffin 提交于
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
-
由 Sean Griffin 提交于
Part of a larger refactoring to remove type casting from Arel. /cc @mrgilman [Sean Griffin & Melanie Gilman]
-
由 Sean Griffin 提交于
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
-
由 Sean Griffin 提交于
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]
-
由 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.
-