2018-09-06 21:46:54 -04:00
|
|
|
* Configuration item `config.filter_parameters` could also filter out sensitive value of database column when call `#inspect`.
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
Rails.application.config.filter_parameters += [:credit_card_number]
|
2018-09-10 15:43:07 -04:00
|
|
|
Account.last.inspect # => #<Account id: 123, credit_card_number: [FILTERED] ...>
|
2018-09-06 21:46:54 -04:00
|
|
|
```
|
|
|
|
|
|
|
|
|
|
*Zhang Kang*
|
|
|
|
|
|
2018-09-05 10:45:52 -04:00
|
|
|
* Deprecate `column_name_length`, `table_name_length`, `columns_per_table`,
|
|
|
|
|
`indexes_per_table`, `columns_per_multicolumn_index`, `sql_query_length`,
|
|
|
|
|
and `joins_per_query` methods in `DatabaseLimits`.
|
|
|
|
|
|
|
|
|
|
*Ryuta Kamizono*
|
|
|
|
|
|
2018-09-06 18:56:31 -04:00
|
|
|
* `ActiveRecord::Base.configurations` now returns an object.
|
Refactors Active Record connection management
While the three-tier config makes it easier to define databases for
multiple database applications, it quickly became clear to offer full
support for multiple databases we need to change the way the connections
hash was handled.
A three-tier config means that when Rails needed to choose a default
configuration (in the case a user doesn't ask for a specific
configuration) it wasn't clear to Rails which the default was. I
[bandaid fixed this so the rake tasks could work](#32271) but that fix
wasn't correct because it actually doubled up the configuration hashes.
Instead of attemping to manipulate the hashes @tenderlove and I decided
that it made more sense if we converted the hashes to objects so we can
easily ask those object questions. In a three tier config like this:
```
development:
primary:
database: "my_primary_db"
animals:
database; "my_animals_db"
```
We end up with an object like this:
```
@configurations=[
#<ActiveRecord::DatabaseConfigurations::HashConfig:0x00007fd1acbded10
@env_name="development",@spec_name="primary",
@config={"adapter"=>"sqlite3", "database"=>"db/development.sqlite3"}>,
#<ActiveRecord::DatabaseConfigurations::HashConfig:0x00007fd1acbdea90
@env_name="development",@spec_name="animals",
@config={"adapter"=>"sqlite3", "database"=>"db/development.sqlite3"}>
]>
```
The configurations setter takes the database configuration set by your
application and turns them into an
`ActiveRecord::DatabaseConfigurations` object that has one getter -
`@configurations` which is an array of all the database objects.
The configurations getter returns this object by default since it acts
like a hash in most of the cases we need. For example if you need to
access the default `development` database we can simply request it as we
did before:
```
ActiveRecord::Base.configurations["development"]
```
This will return primary development database configuration hash:
```
{ "database" => "my_primary_db" }
```
Internally all of Active Record has been converted to use the new
objects. I've built this to be backwards compatible but allow for
accessing the hash if needed for a deprecation period. To get the
original hash instead of the object you can either add `to_h` on the
configurations call or pass `legacy: true` to `configurations.
```
ActiveRecord::Base.configurations.to_h
=> { "development => { "database" => "my_primary_db" } }
ActiveRecord::Base.configurations(legacy: true)
=> { "development => { "database" => "my_primary_db" } }
```
The new configurations object allows us to iterate over the Active
Record configurations without losing the known environment or
specification name for that configuration. You can also select all the
configs for an env or env and spec. With this we can always ask
any object what environment it belongs to:
```
db_configs = ActiveRecord::Base.configurations.configurations_for("development")
=> #<ActiveRecord::DatabaseConfigurations:0x00007fd1acbdf800
@configurations=[
#<ActiveRecord::DatabaseConfigurations::HashConfig:0x00007fd1acbded10
@env_name="development",@spec_name="primary",
@config={"adapter"=>"sqlite3", "database"=>"db/development.sqlite3"}>,
#<ActiveRecord::DatabaseConfigurations::HashConfig:0x00007fd1acbdea90
@env_name="development",@spec_name="animals",
@config={"adapter"=>"sqlite3", "database"=>"db/development.sqlite3"}>
]>
db_config.env_name
=> "development"
db_config.spec_name
=> "primary"
db_config.config
=> { "adapter"=>"sqlite3", "database"=>"db/development.sqlite3" }
```
The configurations object is more flexible than the configurations hash
and will allow us to build on top of the connection management in order
to add support for primary/replica connections, sharding, and
constructing queries for associations that live in multiple databases.
2018-08-16 15:49:18 -04:00
|
|
|
|
2018-09-06 18:56:31 -04:00
|
|
|
`ActiveRecord::Base.configurations` used to return a hash, but this
|
Refactors Active Record connection management
While the three-tier config makes it easier to define databases for
multiple database applications, it quickly became clear to offer full
support for multiple databases we need to change the way the connections
hash was handled.
A three-tier config means that when Rails needed to choose a default
configuration (in the case a user doesn't ask for a specific
configuration) it wasn't clear to Rails which the default was. I
[bandaid fixed this so the rake tasks could work](#32271) but that fix
wasn't correct because it actually doubled up the configuration hashes.
Instead of attemping to manipulate the hashes @tenderlove and I decided
that it made more sense if we converted the hashes to objects so we can
easily ask those object questions. In a three tier config like this:
```
development:
primary:
database: "my_primary_db"
animals:
database; "my_animals_db"
```
We end up with an object like this:
```
@configurations=[
#<ActiveRecord::DatabaseConfigurations::HashConfig:0x00007fd1acbded10
@env_name="development",@spec_name="primary",
@config={"adapter"=>"sqlite3", "database"=>"db/development.sqlite3"}>,
#<ActiveRecord::DatabaseConfigurations::HashConfig:0x00007fd1acbdea90
@env_name="development",@spec_name="animals",
@config={"adapter"=>"sqlite3", "database"=>"db/development.sqlite3"}>
]>
```
The configurations setter takes the database configuration set by your
application and turns them into an
`ActiveRecord::DatabaseConfigurations` object that has one getter -
`@configurations` which is an array of all the database objects.
The configurations getter returns this object by default since it acts
like a hash in most of the cases we need. For example if you need to
access the default `development` database we can simply request it as we
did before:
```
ActiveRecord::Base.configurations["development"]
```
This will return primary development database configuration hash:
```
{ "database" => "my_primary_db" }
```
Internally all of Active Record has been converted to use the new
objects. I've built this to be backwards compatible but allow for
accessing the hash if needed for a deprecation period. To get the
original hash instead of the object you can either add `to_h` on the
configurations call or pass `legacy: true` to `configurations.
```
ActiveRecord::Base.configurations.to_h
=> { "development => { "database" => "my_primary_db" } }
ActiveRecord::Base.configurations(legacy: true)
=> { "development => { "database" => "my_primary_db" } }
```
The new configurations object allows us to iterate over the Active
Record configurations without losing the known environment or
specification name for that configuration. You can also select all the
configs for an env or env and spec. With this we can always ask
any object what environment it belongs to:
```
db_configs = ActiveRecord::Base.configurations.configurations_for("development")
=> #<ActiveRecord::DatabaseConfigurations:0x00007fd1acbdf800
@configurations=[
#<ActiveRecord::DatabaseConfigurations::HashConfig:0x00007fd1acbded10
@env_name="development",@spec_name="primary",
@config={"adapter"=>"sqlite3", "database"=>"db/development.sqlite3"}>,
#<ActiveRecord::DatabaseConfigurations::HashConfig:0x00007fd1acbdea90
@env_name="development",@spec_name="animals",
@config={"adapter"=>"sqlite3", "database"=>"db/development.sqlite3"}>
]>
db_config.env_name
=> "development"
db_config.spec_name
=> "primary"
db_config.config
=> { "adapter"=>"sqlite3", "database"=>"db/development.sqlite3" }
```
The configurations object is more flexible than the configurations hash
and will allow us to build on top of the connection management in order
to add support for primary/replica connections, sharding, and
constructing queries for associations that live in multiple databases.
2018-08-16 15:49:18 -04:00
|
|
|
is an inflexible data model. In order to improve multiple-database
|
|
|
|
|
handling in Rails, we've changed this to return an object. Some methods
|
|
|
|
|
are provided to make the object behave hash-like in order to ease the
|
|
|
|
|
transition process. Since most applications don't manipulate the hash
|
|
|
|
|
we've decided to add backwards-compatible functionality that will throw
|
|
|
|
|
a deprecation warning if used, however calling `ActiveRecord::Base.configurations`
|
|
|
|
|
will use the new version internally and externally.
|
|
|
|
|
|
2018-09-08 09:06:23 -04:00
|
|
|
For example, the following `database.yml`:
|
Refactors Active Record connection management
While the three-tier config makes it easier to define databases for
multiple database applications, it quickly became clear to offer full
support for multiple databases we need to change the way the connections
hash was handled.
A three-tier config means that when Rails needed to choose a default
configuration (in the case a user doesn't ask for a specific
configuration) it wasn't clear to Rails which the default was. I
[bandaid fixed this so the rake tasks could work](#32271) but that fix
wasn't correct because it actually doubled up the configuration hashes.
Instead of attemping to manipulate the hashes @tenderlove and I decided
that it made more sense if we converted the hashes to objects so we can
easily ask those object questions. In a three tier config like this:
```
development:
primary:
database: "my_primary_db"
animals:
database; "my_animals_db"
```
We end up with an object like this:
```
@configurations=[
#<ActiveRecord::DatabaseConfigurations::HashConfig:0x00007fd1acbded10
@env_name="development",@spec_name="primary",
@config={"adapter"=>"sqlite3", "database"=>"db/development.sqlite3"}>,
#<ActiveRecord::DatabaseConfigurations::HashConfig:0x00007fd1acbdea90
@env_name="development",@spec_name="animals",
@config={"adapter"=>"sqlite3", "database"=>"db/development.sqlite3"}>
]>
```
The configurations setter takes the database configuration set by your
application and turns them into an
`ActiveRecord::DatabaseConfigurations` object that has one getter -
`@configurations` which is an array of all the database objects.
The configurations getter returns this object by default since it acts
like a hash in most of the cases we need. For example if you need to
access the default `development` database we can simply request it as we
did before:
```
ActiveRecord::Base.configurations["development"]
```
This will return primary development database configuration hash:
```
{ "database" => "my_primary_db" }
```
Internally all of Active Record has been converted to use the new
objects. I've built this to be backwards compatible but allow for
accessing the hash if needed for a deprecation period. To get the
original hash instead of the object you can either add `to_h` on the
configurations call or pass `legacy: true` to `configurations.
```
ActiveRecord::Base.configurations.to_h
=> { "development => { "database" => "my_primary_db" } }
ActiveRecord::Base.configurations(legacy: true)
=> { "development => { "database" => "my_primary_db" } }
```
The new configurations object allows us to iterate over the Active
Record configurations without losing the known environment or
specification name for that configuration. You can also select all the
configs for an env or env and spec. With this we can always ask
any object what environment it belongs to:
```
db_configs = ActiveRecord::Base.configurations.configurations_for("development")
=> #<ActiveRecord::DatabaseConfigurations:0x00007fd1acbdf800
@configurations=[
#<ActiveRecord::DatabaseConfigurations::HashConfig:0x00007fd1acbded10
@env_name="development",@spec_name="primary",
@config={"adapter"=>"sqlite3", "database"=>"db/development.sqlite3"}>,
#<ActiveRecord::DatabaseConfigurations::HashConfig:0x00007fd1acbdea90
@env_name="development",@spec_name="animals",
@config={"adapter"=>"sqlite3", "database"=>"db/development.sqlite3"}>
]>
db_config.env_name
=> "development"
db_config.spec_name
=> "primary"
db_config.config
=> { "adapter"=>"sqlite3", "database"=>"db/development.sqlite3" }
```
The configurations object is more flexible than the configurations hash
and will allow us to build on top of the connection management in order
to add support for primary/replica connections, sharding, and
constructing queries for associations that live in multiple databases.
2018-08-16 15:49:18 -04:00
|
|
|
|
|
|
|
|
```
|
|
|
|
|
development:
|
|
|
|
|
adapter: sqlite3
|
|
|
|
|
database: db/development.sqlite3
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
Used to become a hash:
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
{ "development" => { "adapter" => "sqlite3", "database" => "db/development.sqlite3" } }
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
Is now converted into the following object:
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
#<ActiveRecord::DatabaseConfigurations:0x00007fd1acbdf800 @configurations=[
|
|
|
|
|
#<ActiveRecord::DatabaseConfigurations::HashConfig:0x00007fd1acbded10 @env_name="development",
|
|
|
|
|
@spec_name="primary", @config={"adapter"=>"sqlite3", "database"=>"db/development.sqlite3"}>
|
|
|
|
|
]
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
Iterating over the database configurations has also changed. Instead of
|
|
|
|
|
calling hash methods on the `configurations` hash directly, a new method `configs_for` has
|
2018-09-08 09:06:23 -04:00
|
|
|
been provided that allows you to select the correct configuration. `env_name`, and
|
|
|
|
|
`spec_name` arguments are optional. For example these return an array of
|
|
|
|
|
database config objects for the requested environment and a single database config object
|
|
|
|
|
will be returned for the requested environment and specification name respectively.
|
Refactors Active Record connection management
While the three-tier config makes it easier to define databases for
multiple database applications, it quickly became clear to offer full
support for multiple databases we need to change the way the connections
hash was handled.
A three-tier config means that when Rails needed to choose a default
configuration (in the case a user doesn't ask for a specific
configuration) it wasn't clear to Rails which the default was. I
[bandaid fixed this so the rake tasks could work](#32271) but that fix
wasn't correct because it actually doubled up the configuration hashes.
Instead of attemping to manipulate the hashes @tenderlove and I decided
that it made more sense if we converted the hashes to objects so we can
easily ask those object questions. In a three tier config like this:
```
development:
primary:
database: "my_primary_db"
animals:
database; "my_animals_db"
```
We end up with an object like this:
```
@configurations=[
#<ActiveRecord::DatabaseConfigurations::HashConfig:0x00007fd1acbded10
@env_name="development",@spec_name="primary",
@config={"adapter"=>"sqlite3", "database"=>"db/development.sqlite3"}>,
#<ActiveRecord::DatabaseConfigurations::HashConfig:0x00007fd1acbdea90
@env_name="development",@spec_name="animals",
@config={"adapter"=>"sqlite3", "database"=>"db/development.sqlite3"}>
]>
```
The configurations setter takes the database configuration set by your
application and turns them into an
`ActiveRecord::DatabaseConfigurations` object that has one getter -
`@configurations` which is an array of all the database objects.
The configurations getter returns this object by default since it acts
like a hash in most of the cases we need. For example if you need to
access the default `development` database we can simply request it as we
did before:
```
ActiveRecord::Base.configurations["development"]
```
This will return primary development database configuration hash:
```
{ "database" => "my_primary_db" }
```
Internally all of Active Record has been converted to use the new
objects. I've built this to be backwards compatible but allow for
accessing the hash if needed for a deprecation period. To get the
original hash instead of the object you can either add `to_h` on the
configurations call or pass `legacy: true` to `configurations.
```
ActiveRecord::Base.configurations.to_h
=> { "development => { "database" => "my_primary_db" } }
ActiveRecord::Base.configurations(legacy: true)
=> { "development => { "database" => "my_primary_db" } }
```
The new configurations object allows us to iterate over the Active
Record configurations without losing the known environment or
specification name for that configuration. You can also select all the
configs for an env or env and spec. With this we can always ask
any object what environment it belongs to:
```
db_configs = ActiveRecord::Base.configurations.configurations_for("development")
=> #<ActiveRecord::DatabaseConfigurations:0x00007fd1acbdf800
@configurations=[
#<ActiveRecord::DatabaseConfigurations::HashConfig:0x00007fd1acbded10
@env_name="development",@spec_name="primary",
@config={"adapter"=>"sqlite3", "database"=>"db/development.sqlite3"}>,
#<ActiveRecord::DatabaseConfigurations::HashConfig:0x00007fd1acbdea90
@env_name="development",@spec_name="animals",
@config={"adapter"=>"sqlite3", "database"=>"db/development.sqlite3"}>
]>
db_config.env_name
=> "development"
db_config.spec_name
=> "primary"
db_config.config
=> { "adapter"=>"sqlite3", "database"=>"db/development.sqlite3" }
```
The configurations object is more flexible than the configurations hash
and will allow us to build on top of the connection management in order
to add support for primary/replica connections, sharding, and
constructing queries for associations that live in multiple databases.
2018-08-16 15:49:18 -04:00
|
|
|
|
|
|
|
|
```
|
2018-09-08 09:06:23 -04:00
|
|
|
ActiveRecord::Base.configurations.configs_for(env_name: "development")
|
|
|
|
|
ActiveRecord::Base.configurations.configs_for(env_name: "development", spec_name: "primary")
|
Refactors Active Record connection management
While the three-tier config makes it easier to define databases for
multiple database applications, it quickly became clear to offer full
support for multiple databases we need to change the way the connections
hash was handled.
A three-tier config means that when Rails needed to choose a default
configuration (in the case a user doesn't ask for a specific
configuration) it wasn't clear to Rails which the default was. I
[bandaid fixed this so the rake tasks could work](#32271) but that fix
wasn't correct because it actually doubled up the configuration hashes.
Instead of attemping to manipulate the hashes @tenderlove and I decided
that it made more sense if we converted the hashes to objects so we can
easily ask those object questions. In a three tier config like this:
```
development:
primary:
database: "my_primary_db"
animals:
database; "my_animals_db"
```
We end up with an object like this:
```
@configurations=[
#<ActiveRecord::DatabaseConfigurations::HashConfig:0x00007fd1acbded10
@env_name="development",@spec_name="primary",
@config={"adapter"=>"sqlite3", "database"=>"db/development.sqlite3"}>,
#<ActiveRecord::DatabaseConfigurations::HashConfig:0x00007fd1acbdea90
@env_name="development",@spec_name="animals",
@config={"adapter"=>"sqlite3", "database"=>"db/development.sqlite3"}>
]>
```
The configurations setter takes the database configuration set by your
application and turns them into an
`ActiveRecord::DatabaseConfigurations` object that has one getter -
`@configurations` which is an array of all the database objects.
The configurations getter returns this object by default since it acts
like a hash in most of the cases we need. For example if you need to
access the default `development` database we can simply request it as we
did before:
```
ActiveRecord::Base.configurations["development"]
```
This will return primary development database configuration hash:
```
{ "database" => "my_primary_db" }
```
Internally all of Active Record has been converted to use the new
objects. I've built this to be backwards compatible but allow for
accessing the hash if needed for a deprecation period. To get the
original hash instead of the object you can either add `to_h` on the
configurations call or pass `legacy: true` to `configurations.
```
ActiveRecord::Base.configurations.to_h
=> { "development => { "database" => "my_primary_db" } }
ActiveRecord::Base.configurations(legacy: true)
=> { "development => { "database" => "my_primary_db" } }
```
The new configurations object allows us to iterate over the Active
Record configurations without losing the known environment or
specification name for that configuration. You can also select all the
configs for an env or env and spec. With this we can always ask
any object what environment it belongs to:
```
db_configs = ActiveRecord::Base.configurations.configurations_for("development")
=> #<ActiveRecord::DatabaseConfigurations:0x00007fd1acbdf800
@configurations=[
#<ActiveRecord::DatabaseConfigurations::HashConfig:0x00007fd1acbded10
@env_name="development",@spec_name="primary",
@config={"adapter"=>"sqlite3", "database"=>"db/development.sqlite3"}>,
#<ActiveRecord::DatabaseConfigurations::HashConfig:0x00007fd1acbdea90
@env_name="development",@spec_name="animals",
@config={"adapter"=>"sqlite3", "database"=>"db/development.sqlite3"}>
]>
db_config.env_name
=> "development"
db_config.spec_name
=> "primary"
db_config.config
=> { "adapter"=>"sqlite3", "database"=>"db/development.sqlite3" }
```
The configurations object is more flexible than the configurations hash
and will allow us to build on top of the connection management in order
to add support for primary/replica connections, sharding, and
constructing queries for associations that live in multiple databases.
2018-08-16 15:49:18 -04:00
|
|
|
```
|
|
|
|
|
|
|
|
|
|
*Eileen M. Uchitelle*, *Aaron Patterson*
|
|
|
|
|
|
2018-08-22 09:00:01 -04:00
|
|
|
* Add database configuration to disable advisory locks.
|
|
|
|
|
|
|
|
|
|
```
|
|
|
|
|
production:
|
|
|
|
|
adapter: postgresql
|
|
|
|
|
advisory_locks: false
|
|
|
|
|
```
|
|
|
|
|
|
|
|
|
|
*Guo Xiang*
|
|
|
|
|
|
2018-08-06 07:38:44 -04:00
|
|
|
* SQLite3 adapter `alter_table` method restores foreign keys.
|
|
|
|
|
|
|
|
|
|
*Yasuo Honda*
|
|
|
|
|
|
2018-08-14 17:29:59 -04:00
|
|
|
* Allow `:to_table` option to `invert_remove_foreign_key`.
|
|
|
|
|
|
|
|
|
|
Example:
|
|
|
|
|
|
|
|
|
|
remove_foreign_key :accounts, to_table: :owners
|
|
|
|
|
|
|
|
|
|
*Nikolay Epifanov*, *Rich Chen*
|
|
|
|
|
|
2015-10-07 05:45:31 -04:00
|
|
|
* Add environment & load_config dependency to `bin/rake db:seed` to enable
|
|
|
|
|
seed load in environments without Rails and custom DB configuration
|
|
|
|
|
|
|
|
|
|
*Tobias Bielohlawek*
|
|
|
|
|
|
2018-07-08 15:06:06 -04:00
|
|
|
* Fix default value for mysql time types with specified precision.
|
2018-07-03 03:17:40 -04:00
|
|
|
|
|
|
|
|
*Nikolay Kondratyev*
|
|
|
|
|
|
2018-06-09 04:30:00 -04:00
|
|
|
* Fix `touch` option to behave consistently with `Persistence#touch` method.
|
|
|
|
|
|
|
|
|
|
*Ryuta Kamizono*
|
|
|
|
|
|
2018-05-30 23:49:25 -04:00
|
|
|
* Migrations raise when duplicate column definition.
|
|
|
|
|
|
|
|
|
|
Fixes #33024.
|
|
|
|
|
|
|
|
|
|
*Federico Martinez*
|
2018-06-10 07:39:10 -04:00
|
|
|
|
2018-06-01 02:55:40 -04:00
|
|
|
* Bump minimum SQLite version to 3.8
|
|
|
|
|
|
|
|
|
|
*Yasuo Honda*
|
|
|
|
|
|
2018-05-28 17:56:46 -04:00
|
|
|
* Fix parent record should not get saved with duplicate children records.
|
2018-05-22 09:34:24 -04:00
|
|
|
|
2018-05-28 17:56:46 -04:00
|
|
|
Fixes #32940.
|
2018-05-22 09:34:24 -04:00
|
|
|
|
|
|
|
|
*Santosh Wadghule*
|
|
|
|
|
|
2018-05-03 20:27:20 -04:00
|
|
|
* Fix logic on disabling commit callbacks so they are not called unexpectedly when errors occur.
|
|
|
|
|
|
|
|
|
|
*Brian Durand*
|
|
|
|
|
|
2018-04-17 21:56:33 -04:00
|
|
|
* Ensure `Associations::CollectionAssociation#size` and `Associations::CollectionAssociation#empty?`
|
|
|
|
|
use loaded association ids if present.
|
|
|
|
|
|
|
|
|
|
*Graham Turner*
|
|
|
|
|
|
2018-04-19 20:56:49 -04:00
|
|
|
* Add support to preload associations of polymorphic associations when not all the records have the requested associations.
|
|
|
|
|
|
|
|
|
|
*Dana Sherson*
|
|
|
|
|
|
2017-12-19 13:42:46 -05:00
|
|
|
* Add `touch_all` method to `ActiveRecord::Relation`.
|
|
|
|
|
|
|
|
|
|
Example:
|
|
|
|
|
|
|
|
|
|
Person.where(name: "David").touch_all(time: Time.new(2020, 5, 16, 0, 0, 0))
|
|
|
|
|
|
|
|
|
|
*fatkodima*, *duggiefresh*
|
|
|
|
|
|
2018-04-02 10:30:24 -04:00
|
|
|
* Add `ActiveRecord::Base.base_class?` predicate.
|
2018-04-02 07:17:24 -04:00
|
|
|
|
|
|
|
|
*Bogdan Gusiev*
|
|
|
|
|
|
2018-06-12 22:03:03 -04:00
|
|
|
* Add custom prefix/suffix options to `ActiveRecord::Store.store_accessor`.
|
2018-03-20 02:02:23 -04:00
|
|
|
|
2018-06-12 22:03:03 -04:00
|
|
|
*Tan Huynh*, *Yukio Mizuta*
|
2018-03-20 02:02:23 -04:00
|
|
|
|
2018-02-17 16:02:18 -05:00
|
|
|
* Rails 6 requires Ruby 2.4.1 or newer.
|
|
|
|
|
|
|
|
|
|
*Jeremy Daer*
|
|
|
|
|
|
2018-02-14 21:33:02 -05:00
|
|
|
* Deprecate `update_attributes`/`!` in favor of `update`/`!`.
|
|
|
|
|
|
|
|
|
|
*Eddie Lebow*
|
2018-02-14 19:51:15 -05:00
|
|
|
|
2018-09-06 18:56:31 -04:00
|
|
|
* Add `ActiveRecord::Base.create_or_find_by`/`!` to deal with the SELECT/INSERT race condition in
|
|
|
|
|
`ActiveRecord::Base.find_or_create_by`/`!` by leaning on unique constraints in the database.
|
2018-02-14 19:51:15 -05:00
|
|
|
|
|
|
|
|
*DHH*
|
2018-01-29 07:28:42 -05:00
|
|
|
|
2018-02-18 10:01:46 -05:00
|
|
|
* Add `Relation#pick` as short-hand for single-value plucks.
|
|
|
|
|
|
|
|
|
|
*DHH*
|
|
|
|
|
|
2018-01-29 07:28:42 -05:00
|
|
|
|
2018-01-30 18:51:17 -05:00
|
|
|
Please check [5-2-stable](https://github.com/rails/rails/blob/5-2-stable/activerecord/CHANGELOG.md) for previous changes.
|