.. not a general timeout.
Now, if a thread checks out a connection then dies, we can immediately
recover that connection and re-use it.
This should alleviate the pool exhaustion discussed in #12867. More
importantly, it entirely avoids the potential issues of the reaper
attempting to check whether connections are still active: as long as the
owning thread is alive, the connection is its business alone.
As a no-op reap is now trivial (only entails checking a thread status
per connection), we can also perform one in-line any time we decide to
sleep for a connection.
Allows fixtures to use their $LABEL as part of a string instead
of limiting use to the entire value.
mark:
first_name: $LABEL
username: $LABEL1973
email: $LABEL@$LABELmail.com
users(:mark).first_name # => mark
users(:mark).username # => mark1973
users(:mark).email # => mark@markmail.com
This behavior has almost no performance impact:
String not allowed 66.910000 0.030000 66.940000 ( 67.024976)
String allowed 69.360000 0.030000 69.390000 ( 69.503096)
Benchmarked with http://git.io/Y0YuRw.
This is a partial revert of 22b3481ba2aa55fad1f9a5db94072312b345fb55.
The current implementation of `references_eager_loaded_tables?` needs to know
every table involved in the query. With the current API this is not possible
without SQL parsing.
While a2dab46cae35a06fd5c5500037177492a047c252 deprecated SQL parsing for `includes`.
It did not issue deprecation warnings when String joins are involved. This resulted
in a breaking change after the deprecated behavior was removed (22b3481ba2aa55fad1f9a5db94072312b345fb55).
We will need to rethink the usage of `includes`, `preload` and `eager_load` but for now,
this brings back the old *working* behavior.
This fixes a bug where any enum attribute of a model
would be evaluated always as 0 when calling the
database on validations.
This fix converts the value of the enum attribute
to its integer value rather than the string before
building the relation as the bug occured when the
string finally gets converted to integer using
string.to_i which converts it to 0.
[Vilius Luneckas, Ahmed AbouElhamayed]
`before_add` callbacks are fired before the record is saved on
`has_and_belongs_to_many` assocations *and* on `has_many :through`
associations. Before this change, `before_add` callbacks would be fired
before the record was saved on `has_and_belongs_to_many` associations, but
*not* on `has_many :through` associations.
Fixes#14144
conflicting private method defined on its ancestors.
The problem is that `method_defined_within?(name, klass, superklass)`
only works correclty when `klass` and `superklass` are both `Class`es.
If both `klass` and `superklass` are both `Class`es, they share the
same inheritance chain, so if a method is defined on `klass` but not
`superklass`, this method must be introduced at some point between
`klass` and `superklass`.
This does not work when `superklass` is a `Module`. A `Module`'s
inheritance chain contains just itself. So if a method is defined on
`klass` but not on `superklass`, the method could still be defined
somewhere upstream, e.g. in `Object`.
This fix works by avoiding calling `method_defined_within?` with a
module while still fufilling the requirement (checking that the
method is defined withing `superclass` but not is not a generated
attribute method).
4d8ee288 is likely an attempted partial fix for this problem. This
unrolls that fix and properly check the `superclass` as intended.
Fixes#11569.
The Ruby Range object does not support excluding beginnings.
We currently support excluding beginnings for some subtypes using
manually by incrementing them (now using the `#succ` method).
This is approach is flawed as it's not equal to an excluding beginning.
This commit deprecates the current support for excluding beginnings.
It also raises an `ArgumentError` for subtypes that do not implement the `succ`
method.
This is a temporary solution to get rid of the broken state. We might still
add complete support for excluding beginnings afterwards. (Probably with a
new `PGRange` object, which acts like a `Range` but has excluding beginnings.
This gets AR working with custom defined range types. It also
removes the need for subtype specific branches in `OID::Range`.
This expands the interface of all `OID` types with the `infinity` method.
It's responsible to provide a value for positive and negative infinity.
This reverts commit 3ea840355409dc205a9e0d027fc09f1452636969, reversing
changes made to e4cde5d58cbb09d1843796f96ba86225ff94fe05.
Conflicts:
activerecord/CHANGELOG.md
activerecord/lib/active_record/relation/query_methods.rb
Reason: using `from` without `select` should not change the select list
to SELECT * because it can lead different query results. If it is needed
to change the table to a subquery or a view you can pass a table alias
in the `from` call or use `select('subquery.*')`.
Fixes#14049.
We didn't have enough encoding for the wire protocol to store an array
of hstore types. So, further encode any hstore that is an array member.
Whilst we're here, ensure it's an HashWithIndifferentAccess being
returned, to be consistent with other serialized forms, and add testing
for arrays of hstore.
So now the following migration:
enable_extension "hstore"
create_table :servers do |t|
t.string :name
t.hstore :interfaces, array: true
end
produces a model that can used like this, to store an array of hashes:
server = Server.create(name: "server01", interfaces: [
{ name: "bge0", ipv4: "192.0.2.2", state: "up" },
{ name: "de0", state: "disabled", by: "misha" },
{ name: "fe0", state: "up" },
])
More at http://inopinatus.org/2013/07/12/using-arrays-of-hstore-with-rails-4/
* Add a config on Active Record named `dump_schema_after_migration`
* Schema dump doesn't happen if the config is set to false
* Set default value of the config to true
* Set config in generated production environment file to false
* Update configuration guide
* Update CHANGELOG
This was a common pattern:
```
query = author.posts.select(:title)
connection.select_one(query)
```
However `.select` returns a ActiveRecord::AssociationRelation, which has
the bind information, so we can use that to get the right sql query.
Also fix select_rows on postgress and sqlite3 that were not using the binds
[fixes#7538]
[fixes#12017]
[related #13731]
[related #12056]
