The `#[]` method *used to be* an alias of `#read_attribute`, but since Rails 4
(10f6f90d9d1bbc9598bffea90752fc6bd76904cd), it will raise an exception for
missing attributes. Saying that it is an alias is confusing.
After PR https://github.com/rails/rails/pull/24844 the documentation for
`#retrieve_connection_pool` was out of date. This commit changes:
- the reference from `@class_to_pool` to `@owner_to_pool`.
- with newer Rubies, `#fetch` isn't significantly slower than `#[]`. Since Rails 5
requires Ruby >= 2.2.2, we can just use `#fetch` here.
Ruby 2.4 unifies Fixnum and Bignum into Integer: https://bugs.ruby-lang.org/issues/12005
* Forward compat with new unified Integer class in Ruby 2.4+.
* Backward compat with separate Fixnum/Bignum in Ruby 2.2 & 2.3.
* Drops needless Fixnum distinction in docs, preferring Integer.
If a call to #suppress from the same class occurred inside another #suppress
block, the suppression state would be set to false before the outer block
completes.
This change keeps the previous state around in memory and unwinds it
as the blocks exit.
The error message that we give today makes this error difficult to debug
if you receive it. I have no clue why we're printing the object ID of
the class (the commit doesn't give context), but I've left it as it was
deliberate.
When looking for mutation, we compare the serialized version of the
value to the before_type_cast form. `Type::Serialized` was breaking this
contract by passing the already serialized attribute to the subtype's
mutation detection. This never manifested previously, as all mutable
subtypes either didn't do anything in their `serialize` method, or had a
way to detect double serialization (e.g. `is_a?(String)`). However, now
that JSON types can handle string primitives, we need to avoid double
serialization.
Fixes#24993.
`remove_connection` can reset the `connection_specification_name`, so we
need to to set it after the remove_connection call on
`establish_connection` method.
We cannot cache the connection_specification_name when it doesnt
exist. Thats because the parent value could change, and we should keep
failling back to the parent. If we cache that in a children as an ivar,
we would not fallback anymore in the next call, so the children would
not get the new parent spec_name.
Follow up of #24844.
The key of `@owner_to_pool` was changed from `klass.name` to
`spec.name`. By this change "memory leaks in development mode"
will not happen, bacause the equality of string is not changed
by reloading of model files.
remove_connection
When calling `remove_connection` on a model, we delete the pool so we also
need to reset the `connection_specification_name` so it will fallback to
the parent.
This was the current behavior before rails 5, which will fallback to the
parent connection pool.
[fixes#24959]
Special thanks to @jrafanie for working with me on this fix.
If an attribute was of the binary type, and also was a Hash, it would
previously not be logged, and instead raise an error saying that
`bytesize` was not defined for the `attribute.value` (a `Hash`).
Now, as is done on 4-2-stable, the attribute's database value is
`bytesize`d, and then logged out to the terminal.
Reproduction script:
```ruby
require 'active_record'
require 'minitest/autorun'
require 'logger'
ActiveRecord::Base.establish_connection(adapter: 'sqlite3', database: ':memory:')
ActiveRecord::Base.logger = Logger.new(STDOUT)
ActiveRecord::Schema.define do
create_table :posts, force: true do |t|
t.binary :preferences
end
end
class Post < ActiveRecord::Base
serialize :preferences
end
class BugTest < Minitest::Test
def test_24955
Post.create!(preferences: {a: 1})
assert_equal 1, Post.count
end
end
```
In 5.0 we use bind parameters for limit and offset, while in 4.2 we used
the values directly. The code as it was written assumed that limit and
offset worked as `LIMIT ? OFFSET ?`. Both Oracle and SQL Server have a
different syntax, where the offset is stated before the limit. We
delegate this behavior to the connection adapter so that these adapters
are able to determine how the bind parameters are flattened based on
what order their specification has the various clauses appear.
Fixes#24775
