- 26 1月, 2015 2 次提交
-
-
由 Sean Griffin 提交于
See 4d7a6229 for the reasoning
-
由 Sean Griffin 提交于
The structure of `values[:where]` is going to change, with an intermediate definition of `where_values` to aid the refactoring. Accessing `values[:where]` directly messes with that, signficantly. The array wrapping is no longer necessary, since `where_values` will always return an array.
-
- 25 1月, 2015 5 次提交
-
-
由 Rémy Coutable 提交于
[ci skip]
-
由 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 5 次提交
-
-
由 Sean Griffin 提交于
Minor style changes across the board. Changed an alias to an explicit method declaration, since the alias will not be documented otherwise.
-
由 Bogdan Gusiev 提交于
Allows to use it for any object as an includable module.
-
由 Sean Griffin 提交于
Given that this was originally added to normalize an error that would have otherwise come from the database (inconsistently), it's more natural for us to raise in `type_cast_for_database`, rather than `type_cast_from_user`. This way, things like numericality validators can handle it instead if the user chooses to do so. It also fixes an issue where assigning an out of range value would make it impossible to assign a new value later. This fixes several vague issues, none of which were ever directly reported, so I have no issue number to give. Places it was mentioned which I can remember: - https://github.com/thoughtbot/shoulda-matchers/blob/9ba21381d7caf045053a81f32df7de2f49687820/lib/shoulda/matchers/active_model/allow_value_matcher.rb#L261-L263 - https://github.com/rails/rails/issues/18653#issuecomment-71197026
-
由 Sean Griffin 提交于
Fixes #18580.
-
由 Sean Griffin 提交于
Fixes #18632
-
- 23 1月, 2015 1 次提交
-
-
由 Santosh Wadghule 提交于
-
- 22 1月, 2015 1 次提交
-
-
由 Sean Griffin 提交于
Keeping with our behavior elsewhere in the system, invalid input is assumed to be `nil`. Fixes #18629.
-
- 21 1月, 2015 3 次提交
-
-
由 Santosh Wadghule 提交于
-
由 Sean Griffin 提交于
This method can be used to see all of the fields on a model which have been read. This can be useful during development mode to quickly find out which fields need to be selected. For performance critical pages, if you are not using all of the fields of a database, an easy performance win is only selecting the fields which you need. By calling this method at the end of a controller action, it's easy to determine which fields need to be selected. While writing this, I also noticed a place for an easy performance win internally which I had been wanting to introduce. You cannot mutate a field which you have not read. Therefore, we can skip the calculation of in place changes if we have never read from the field. This can significantly speed up methods like `#changed?` if any of the fields have an expensive mutable type (like `serialize`) ``` Calculating ------------------------------------- #changed? with serialized column (before) 391.000 i/100ms #changed? with serialized column (after) 1.514k i/100ms ------------------------------------------------- #changed? with serialized column (before) 4.243k (± 3.7%) i/s - 21.505k #changed? with serialized column (after) 16.789k (± 3.2%) i/s - 84.784k ```
-
由 Arthur Neves 提交于
-
- 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`.
-
- 19 1月, 2015 2 次提交
-
-
由 Stefan Kanev 提交于
If set to `if_exists: true`, it generates a statement like: DROP TABLE IF EXISTS posts This syntax is supported in the popular SQL servers, that is (at least) SQLite, PostgreSQL, MySQL, Oracle and MS SQL Sever. Closes #16366.
-
由 Sean Griffin 提交于
When an attribute is assigned, we determine if it was already marked as changed so we can determine if we need to clear the changes, or mark it as changed. Since this only affects the `attributes_changed_by_setter` hash, in-place changes are irrelevant to this process. Since calculating in-place changes can be expensive, we can just skip it here. I also added a test for the only edge case I could think of that would be affected by this change.
-
- 18 1月, 2015 1 次提交
-
-
由 Prathamesh Sonpatki 提交于
- This is based on https://github.com/rails/rails/issues/18400 but tackling same issue with update_attribute method instead of update method.
-
- 16 1月, 2015 4 次提交
-
-
由 brainopia 提交于
after_commit callbacks run after committing a transaction whose parent is not `joinable?`: un-nested transactions, transactions within test cases, and transactions in `console --sandbox`.
-
由 Henrik Nyh 提交于
-
由 Henrik Nyh 提交于
Says it's only used for the schema, but they are in fact used for other things. Integer verifies against the limit during casting, and Decimal uses precision during casting. It may be true that scale is only used for the schema.
-
由 Aditya Kapoor 提交于
-
- 15 1月, 2015 6 次提交
-
-
由 Jeroen K. 提交于
-
由 Sean Griffin 提交于
The types that are affected by `time_zone_aware_attributes` (which is on by default) have been made configurable, in case this is a breaking change for existing applications.
-
由 Sean Griffin 提交于
While we don't want to change the form input when validations fail, blindly using `_before_type_cast` will cause the input to display the wrong data for any type which does additional work on database values.
-
由 Sean Griffin 提交于
Building the Arel AST, and manipulating the relation manually like this is prone to errors and breakage as implementation details change from underneath it.
-
由 Sean Griffin 提交于
Building the Arel AST, and manipulating the relation manually like this is prone to errors and breakage as implementation details change from underneath it.
-
由 Sean Griffin 提交于
This behavior exists only to support fixtures, so we should handle it there. Leaving it in `#quote` can cause very subtle bugs to slip through, by things appearing to work when they should be blowing up loudly, such as #18385.
-
- 13 1月, 2015 2 次提交
-
-
由 Yoshioka Tsuneo 提交于
On reconnection failure, all the connection was released. But, it is better to release only failed connection. This patch changes not to release all the connection but release only failed connection.
-
由 Ethan 提交于
-
- 11 1月, 2015 4 次提交
-
-
由 Sean Griffin 提交于
It's only used to grab the type for type casting purposes, and we would like to remove the type from the columns entirely.
-
由 Sean Griffin 提交于
I'm planning on deprecating the column argument to mirror the deprecation in [arel]. [arel]: https://github.com/rails/arel/commit/6160bfbda1d1781c3b08a33ec4955f170e95be11
-
由 Sean Griffin 提交于
I'm planning on deprecating the column argument to mirror the deprecation in [arel]. [arel]: https://github.com/rails/arel/commit/6160bfbda1d1781c3b08a33ec4955f170e95be11
-
由 Sean Griffin 提交于
I'm planning on deprecating the column argument to mirror the deprecation in [arel]. [arel]: https://github.com/rails/arel/commit/6160bfbda1d1781c3b08a33ec4955f170e95be11
-