- 28 2月, 2015 1 次提交
-
-
由 Akira Matsuda 提交于
[ci skip]
-
- 18 2月, 2015 1 次提交
-
-
由 Sean Griffin 提交于
-
- 01 2月, 2015 1 次提交
-
-
由 Sean Griffin 提交于
It's finally finished!!!!!!! The reason the Attributes API was kept private in 4.2 was due to some publicly visible implementation details. It was previously implemented by overloading `columns` and `columns_hash`, to make them return column objects which were modified with the attribute information. This meant that those methods LIED! We didn't change the database schema. We changed the attribute information on the class. That is wrong! It should be the other way around, where schema loading just calls the attributes API for you. And now it does! Yes, this means that there is nothing that happens in automatic schema loading that you couldn't manually do yourself. (There's still some funky cases where we hit the connection adapter that I need to handle, before we can turn off automatic schema detection entirely.) There were a few weird test failures caused by this that had to be fixed. The main source came from the fact that the attribute methods are now defined in terms of `attribute_names`, which has a clause like `return [] unless table_exists?`. I don't *think* this is an issue, since the only place this caused failures were in a fake adapter which didn't override `table_exists?`. Additionally, there were a few cases where tests were failing because a migration was run, but the model was not reloaded. I'm not sure why these started failing from this change, I might need to clear an additional cache in `reload_schema_from_cache`. Again, since this is not normal usage, and it's expected that `reset_column_information` will be called after the table is modified, I don't think it's a problem. Still, test failures that were unrelated to the change are worrying, and I need to dig into them further. Finally, I spent a lot of time debugging issues with the mutex used in `define_attribute_methods`. I think we can just remove that method entirely, and define the attribute methods *manually* in the call to `define_attribute`, which would simplify the code *tremendously*. Ok. now to make this damn thing public, and work on moving it up to Active Model.
-
- 29 1月, 2015 1 次提交
-
-
由 Sean Griffin 提交于
Fixes #18717
-
- 28 1月, 2015 2 次提交
-
-
由 Sean Griffin 提交于
`bound_attributes` is now used universally across the board, removing the need for the conversion layer. These changes are mostly mechanical, with the exception of the log subscriber. Additional, we had to implement `hash` on the attribute objects, so they could be used as a key for query caching.
-
由 Sean Griffin 提交于
The bind values can come from four places. `having`, `where`, `joins`, and `from` when selecting from a subquery that contains binds. These need to be kept in a specific order, since the clauses will always appear in that order. Up until recently, they were not. Additionally, `joins` actually did keep its bind values in a separate location (presumably because it's the only case that people noticed was broken). However, this meant that anything accessing just `bind_values` was broken (which most places were). This is no longer possible, there is only a single way to access the bind values, and it includes joins in the proper location. The setter was removed yesterday, so breaking `+=` cases is not possible. I'm still not happy that `joins` is putting it's bind values on the Arel AST, and I'm planning on refactoring it further, but this removes a ton of bug cases.
-
- 27 1月, 2015 1 次提交
-
-
由 Sean Griffin 提交于
This fixed an issue where `having` can only be called after the last call to `where`, because it messes with the same `bind_values` array. With this change, the two can be called as many times as needed, in any order, and the final query will be correct. However, once something assigns `bind_values`, that stops. This is because we have to move all of the bind values from the having clause over to the where clause since we can't differentiate the two, and assignment was likely in the form of: `relation.bind_values += other.bind_values` This will go away once we remove all places that are assigning `bind_values`, which is next on the list. While this fixes a bug that was present in at least 4.2 (more likely present going back as far as 3.0, becoming more likely in 4.1 and later as we switched to prepared statements in more cases), I don't think this can be easily backported. The internal changes to `Relation` are non-trivial, anything that involves modifying the `bind_values` array would need to change, and I'm not confident that we have sufficient test coverage of all of those locations (when `having` was called with a hash that could generate bind values). [Sean Griffin & anthonynavarre]
-
- 02 1月, 2015 1 次提交
-
-
由 Rafael Mendonça França 提交于
-
- 11 12月, 2014 1 次提交
-
-
由 Miklos Fazkeas 提交于
-
- 02 11月, 2014 1 次提交
-
-
由 Sean Griffin 提交于
MySQL reports the column name as `"MAX(developer_id)"`. PG will report it as `"max"`
-
- 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
-
- 20 9月, 2014 1 次提交
-
-
由 Godfrey Chan 提交于
The hash is now string-keyed, and [_]reflect_on_association calls `to_s` on the argument anyway.
-
- 03 7月, 2014 1 次提交
-
-
由 Cade Truitt 提交于
-
- 22 6月, 2014 1 次提交
-
-
由 Sean Griffin 提交于
Attempting to reduce the number of places that care about the details of how type casting occurs. We remove the type casting of the primary key in `JoinDependecy`, rather than encapsulating it. It was originally added for consistency with https://github.com/rails/rails/commit/40898c8c19fa04442fc5f8fb5daf3a8bdb9a1e03#diff-06059df8d3dee3101718fb2c01151ad0R211, but that conditional was later removed in https://github.com/rails/rails/commit/d7ddaa530fd1b94e22d745cbaf2e8a5a34ee9734. What is important is that the same row twice will have the same value for the primary key, which it will.
-
- 18 6月, 2014 1 次提交
-
-
由 Sean Griffin 提交于
-
- 17 6月, 2014 1 次提交
-
-
由 Aditya Kapoor 提交于
-
- 12 6月, 2014 1 次提交
-
-
由 Sean Griffin 提交于
The column name given by the adapter doesn't include the table namespace, so going through the hashed version of the result set causes overridden keys. Fixes #15649
-
- 10 6月, 2014 1 次提交
-
-
由 Sean Griffin 提交于
In some cases there is a difference between the two, we should always be doing one or the other. For convenience, `type_cast` is still a private method on type, so new types that do not need different behavior don't need to implement two methods, but it has been moved to private so it cannot be used accidentally.
-
- 04 6月, 2014 1 次提交
-
-
由 eileencodes 提交于
Reflection has a `belongs_to?` method. Instead of checking for `macro == :belongs_to` throughout the source reuse existing method. I also bumped `foreign_key_present?` method onto on line because the `belongs_to?` makes it shorter than other longer lines in the same class.
-
- 03 6月, 2014 1 次提交
-
-
由 Sean Griffin 提交于
This was previously a hook for a special case related to `serialize`, which has since been removed.
-
- 25 5月, 2014 1 次提交
-
-
由 Arthur Neves 提交于
Fix habtm reflection Conflicts: activerecord/CHANGELOG.md activerecord/lib/active_record/counter_cache.rb activerecord/lib/active_record/reflection.rb activerecord/test/cases/reflection_test.rb
-
- 13 5月, 2014 1 次提交
-
-
由 Yves Senn 提交于
-
- 03 5月, 2014 1 次提交
-
-
由 Aaron Patterson 提交于
bind parameters we not being propogated to simple subquery calculation calls. This fixes it
-
- 15 4月, 2014 1 次提交
-
-
由 Lauro Caetano 提交于
968c581e have fixed the EagerLoadTest, but not in the correct way. The problem was when `empty?` or `size` was called on relation. It was triggering `count(:all)`, which was passing `:all` as the column name to `count` on Calculations. On the other hand, the method `calculate` on Calculations was calling `construct_relation_for_association_calculations` instead of `perform_calculation`, because `has_include?` was returning `true` since `column_name` was present. To prevent calling the wrong method to perform the calculation, we have to check if the `column_name` is present and if it is different from `:all` (which is now used to correctly do `count` with `select`). More information here: https://github.com/rails/rails/commit/968c581ea34b5236af14805e6a77913b1cb36238#commitcomment-6006135
-
- 07 4月, 2014 1 次提交
-
-
由 Lauro Caetano 提交于
This is necessary because Postgresql doesn't play nice with ORDER BY and no GROUP BY. Fixes #14621.
-
- 14 1月, 2014 1 次提交
-
-
由 Aaron Patterson 提交于
-
- 11 12月, 2013 2 次提交
-
-
由 Rafael Mendonça França 提交于
-
由 Rafael Mendonça França 提交于
It is needed for activerecord-depecated_finders This reverts commit dcff027a, reversing changes made to 3a209398.
-
- 10 12月, 2013 1 次提交
-
-
由 Paul Nikitochkin 提交于
For PG adapters with custom expression and grouped result of aggregate functions have not found correct column type for it. Extract column type from query result. Closes: #13230
-
- 14 10月, 2013 1 次提交
-
-
由 Vipul A M 提交于
Stop accepting `options` for `Relation#average`, `Relation#minimum`, `Relation#maximum`, `Relation#calculate`, `perform_calculation`, `NullRelation#calculate` as they isn't used anymore.
-
- 13 10月, 2013 1 次提交
-
-
由 Vipul A M 提交于
-
- 31 8月, 2013 1 次提交
-
-
由 Ryan Wallace 提交于
-
- 15 7月, 2013 1 次提交
- 03 7月, 2013 1 次提交
-
-
由 Aaron Patterson 提交于
-
- 02 7月, 2013 6 次提交
-
-
由 Aaron Patterson 提交于
-
由 Aaron Patterson 提交于
-
由 Aaron Patterson 提交于
-
由 Aaron Patterson 提交于
-
由 Aaron Patterson 提交于
-
由 Yves Senn 提交于
-