- 02 9月, 2016 2 次提交
-
-
由 Xavier Noria 提交于
-
由 Xavier Noria 提交于
-
- 01 9月, 2016 4 次提交
-
-
由 Sean Griffin 提交于
The fact that this only includes column names is an oversight.
-
由 Sean Griffin 提交于
There are some minor changes to the point type as I had forgotten that this will affect the behavior of `t.point` in migrations and the schema dumper so we need to handle those as well. I'll say this again so I can convince myself to come up with a better structure... TYPES SHOULD NOT CARE ABOUT SCHEMA DUMPING AND WE NEED TO BETTER SEPARATE THESE.
-
由 Sean Griffin 提交于
This reverts commit 3a1f6fe7. This commit takes the code in a direction that I am looking to avoid. The predicate builder should be purely concerned with AST construction as it matters to methods like `where`. Things like case sensitivity should continue to be handled elsewhere.
-
由 Sean Griffin 提交于
I still think that this is something that should be handled in the pg gem, but it's not going to end up happening there so we'll do it here instead. Once we bump to pg 0.19 we can pass the encoding to the `encode` method instead. This issue occurs because C has no concept of encoding (or strings, really). The bytes that we pass here when sending the value to the database will always be interpreted as whatever encoding the connection is currently configured to use. That means that roundtripping to the database will lose no information However, after assigning we round trip through our type system without hitting the database. The only way that we can do the "correct" thin here would be to actually give a reference to the connection to the array type and have it check the current value of the connection's encoding -- which I'm strongly opposed to. We could also pass in the encoding when it's constructed, but since that can change independently of the type I'm not a huge fan of that either. This feels like a reasonable middle ground, where if we have an array of strings we simply use the encoding of the string we're given. Fixes #26326.
-
- 31 8月, 2016 3 次提交
-
-
由 Sean Griffin 提交于
This was almost every case where we are overriding `respond_to?` in a way that mirrors a parallel implementation of `method_missing`. There is one remaining case in Active Model that should probably do the same thing, but had a sufficiently strange implementation that I want to investigate it separately. Fixes #26333.
-
由 Sean Griffin 提交于
If a parent association was accessed in an `after_find` or `after_initialize` callback, it would always end up loading the association, and then immediately overwriting the association we just loaded. If this occurred in a way that the parent's `current_scope` was set to eager load the child, this would result in an infinite loop and eventually overflow the stack. For records that are created with `.new`, we have a mechanism to perform an action before the callbacks are run. I've introduced the same code path for records created with `instantiate`, and updated all code which sets inverse instances on newly loaded associations to use this block instead. Fixes #26320.
-
由 Santosh Wadghule 提交于
-
- 28 8月, 2016 3 次提交
-
-
由 Ryuta Kamizono 提交于
Rails dropped Ruby 1.9 support, but this comment still true.
-
由 Ryuta Kamizono 提交于
Follow up to #26301.
-
由 Jon Moss 提交于
The performance difference between `Hash[]` and `Hash.dup` looks to have been narrowed by @tenderlove via this commit --> https://github.com/ruby/ruby/commit/b3803cc49ad382e23291d75ce57ffb2b74bb9577#diff-eff9999082c8ce7d8ba1fc1d79f439cf. Since this commit first appeared in Ruby 2.0.0, and since Rails now requires a minimum Ruby version of 2.2.2, this performance boost should be available for all users. Relevant links: - This behavior was originally added via https://github.com/rails/rails/commit/02174a3efc6fa8f2e5e6f114e4cf0d8a06305b6a - The conversation on the Ruby issue tracker lives here --> https://bugs.ruby-lang.org/issues/7166
-
- 26 8月, 2016 4 次提交
-
-
由 James Coleman 提交于
Previously, if the the association was previously loaded and then the foreign key changed by itself, a #save call would trigger a load of the new associated record during autosave. This is unnecessary and the autosave code (in that case) didn't use the loaded record anyways.
-
由 Ryuta Kamizono 提交于
-
由 Ryuta Kamizono 提交于
For simplicity.
-
由 Ryuta Kamizono 提交于
For reduce instantiating `Type::Value`.
-
- 24 8月, 2016 1 次提交
-
-
由 James Coleman 提交于
This is fixed in 5.0 as an ancillary part of 574f2556 but here I also add a test for the condition. I'd previously backported the fix (and added a test) in the below commit; this brings the fix back up to master. (cherry picked from commit fce3dbf3)
-
- 23 8月, 2016 5 次提交
-
-
由 Bogdan Gusiev 提交于
Introduced low level methods #set_value and #get_value for setting query attributes: relation.set_value(:where, {id: 1}) relation.get_value(:includes) Used those internally when working with relation's attributes at the abstract level
-
由 Ryuta Kamizono 提交于
`format_string` is used for standardized column types/arguments spaces. Now the standardization was removed at df84e986.
-
由 Ryuta Kamizono 提交于
-
由 Rafael Mendonça França 提交于
Now the schema dumper by default doesn't align the types and arguments in the ruby format anymore.
-
由 Philip Nguyen 提交于
This is to close #26111 Developers need to be aware that `dependent: :destroy` on a scoped `has_many` association would only destroy the associated objects in that scope. Potentially leaving other associated objects outside that scope untouched.
-
- 20 8月, 2016 1 次提交
-
-
由 Ryuta Kamizono 提交于
Fixes #26137.
-
- 19 8月, 2016 6 次提交
-
-
由 Ryuta Kamizono 提交于
Simply use its own methods because `CollectionProxy` inherits `Relation`.
-
由 Ryuta Kamizono 提交于
-
由 Ryuta Kamizono 提交于
`length` is delegated to `records` (`load_target`) by `ActiveRecord::Delegation`. https://github.com/rails/rails/blob/v5.0.0/activerecord/lib/active_record/relation/delegation.rb#L38
-
由 Rafael Mendonça França 提交于
[Rafael Mendonça França + Robin Dupret]
-
由 Ryuta Kamizono 提交于
This reverts #23067. #23067 is for propagating `pk` value from `sql_for_insert` to `exec_insert` (avoiding extra query for pg adapter). Now `exec_insert` includes `sql_for_insert` since #26002 therefore this propagating is no longer needed.
-
由 Ryuta Kamizono 提交于
Strict mode controls how MySQL handles invalid or missing values in data-change statements such as INSERT or UPDATE. If strict mode is not in effect, MySQL inserts adjusted values for invalid or missing values and produces warnings. ```ruby def test_mysql_not_null_defaults_non_strict using_strict(false) do with_mysql_not_null_table do |klass| record = klass.new assert_nil record.non_null_integer assert_nil record.non_null_string assert_nil record.non_null_text assert_nil record.non_null_blob record.save! record.reload assert_equal 0, record.non_null_integer assert_equal "", record.non_null_string assert_equal "", record.non_null_text assert_equal "", record.non_null_blob end end end ``` It is inconsistent with other types that only text/blob defaults treated as an empty string. This commit fixes the inconsistency.
-
- 18 8月, 2016 5 次提交
-
-
invalid column type /activerecord/lib/active_record/connection_adapters /abstract/schema_definitions.rb:306 type = type.to_sym Changed to the following to handle nil case: type = type.to_sym if type Added regression test for this case: /activerecord/test/cases/migration_test.rb:554 if current_adapter?(:SQLite3Adapter) def test_allows_sqlite3_rollback_on_invalid_column_type Person.connection.create_table :something, force: true do |t| t.column :number, :integer t.column :name, :string t.column :foo, :bar end assert Person.connection.column_exists?(:something, :foo) assert_nothing_raised { Person.connection.remove_column :something, :foo, :bar } assert !Person.connection.column_exists?(:something, :foo) assert Person.connection.column_exists?(:something, :name) assert Person.connection.column_exists?(:something, :number) ensure Person.connection.drop_table :something, if_exists: true end end
-
由 Ryuta Kamizono 提交于
Currently `CollectionProxy` inherits `Relation` therefore we can use its own methods rather than delegating to collection association.
-
由 Ryuta Kamizono 提交于
Currently `CollectionProxy` inherits `Relation` and `Relation` includes `QueryMethods`. This method is completely duplicated. https://github.com/rails/rails/blob/v5.0.0/activerecord/lib/active_record/relation/query_methods.rb#L271-L275
-
由 Ryuta Kamizono 提交于
Because `sql_for_insert` is only called in `use_insert_returning?` is true since #26002.
-
由 Ryuta Kamizono 提交于
Because `sanitize_conditions` protected method is only used in one place.
-
- 17 8月, 2016 2 次提交
-
-
由 Tim Petricola 提交于
-
由 Rafael Mendonça França 提交于
-
- 16 8月, 2016 4 次提交
-
-
由 Ryuta Kamizono 提交于
Otherwise CollectionProxy's bang methdos cannot respect dirty target.
-
由 Ryuta Kamizono 提交于
`#second`, `#third`, etc finder methods was added in 03855e79. But the signature of these methods is inconsistent with the original finder methods. And also the signature of `#first` and `#last` methods is different from the original. This commit fixes the inconsistency.
-
由 Maxime Lapointe 提交于
The current behaviour of checking if there is a LEFT OUTER JOIN arel node to detect if we are doing eager_loading is wrong. This problem wasn't frequent before as only some pretty specific cases would add a LEFT OUTER JOIN arel node. However, the recent new feature left_outer_joins also add this node and made this problem happen frequently. Since in the perform_calculation function, we don't have access to eager_loading information, I had to extract the logic for the distinct out to the calculate method. As I was in the file for left_outer_join tests, I fixed a few that had bugs and I replaced some that were really weak with something that will catch more issues. In relation tests, the first test I changed would have failed if it had validated the hash returned by count instead of just checking how many pairs were in it. This is because this merge of join currently transforms the join node into an outer join node, which then made count do a distinct. So before this change, the return was {1=>1, 4=>1, 5=>1}.
-
由 Jean Boussier 提交于
-