| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Closes #17945
`db:test:prepare` still purges the database to always keep the test
database in a consistent state.
This patch introduces new problems with `db:schema:load`. Prior
to the introduction of foreign-keys, we could run this file against
a non-empty database. Since every `create_table` containted the
`force: true` option, this would recreate tables when loading the schema.
However with foreign-keys in place, `force: true` wont work anymore and
the task will crash.
/cc @schneems
|
| |
|
|
|
|
|
|
|
| |
To be possible to use a custom column name to save/read the polymorphic
associated type in a has_many or has_one polymorphic association, now users
can use the option :foreign_type to inform in what column the associated object
type will be saved.
|
| |
|
|
|
|
| |
Users should pass strings to queries instead of classes
|
|
|
|
| |
[ci skp]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When running the following migration:
change_table(:table_name) { |t| t/timestamps }
The following error was produced:
wrong number of arguments (2 for 1) .... /connection_adapters/abstract/schema_statements.rb:851:in `remove_timestamps'
This is due to `arguments` containing an empty hash as its second
argument.
|
| |
|
|
|
|
|
|
|
| |
We will support only Ruby >= 2.1.
But right now we don't accept pull requests with syntax changes to drop
support to Ruby 1.9.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts deprecations added in #13528.
The task is brought back for two reasons:
1. Give plugins a way to hook into the test database initialization process
2. Give the user a way to force a test database synchronization
While `test:prepare` is still a dependency of every test task, `db:test:prepare`
no longer hooks into it. This means that `test:prepare` runs before the schema
is synchronized. Plugins, which insert data can now hook into `db:test:prepare`.
The automatic schema maintenance can't detect when a migration is rolled-back,
modified and reapplied. In this case the user has to fall back to `db:test:prepare`
to force the synchronization to happen.
|
|\
| |
| | |
Fix includes on association with a scope
|
| |
| |
| |
| | |
on the joined assoiciation
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
`.reflections` public API changed to return a String instead of a Symbol
as keys.
see commit 1f31488499111fdfce79d8dc1cc8fb008f7cdb25 and 6259e4e2dcca9a79f22f96658c33efe81936bc0d
[fixes #16928]
[fixes #17610]
|
|/
|
|
|
|
|
|
| |
Also checked to make sure this does not affect foreign key constraints.
(It doesn't).
Fixes #12856
Closes #14088
|
|
|
|
|
|
|
|
| |
Prior to this patch you'd end up with an error like:
```
ActiveRecord::RecordNotFound: Couldn't find <Model> with 'id'=<id> [WHERE (<default_scope condition>)]
```
|
|\
| |
| |
| | |
add a Table#name accessor like TableDefinition#name
|
|/ |
|
|\
| |
| |
| |
| |
| |
| |
| |
| | |
Empact/association-bind-values-not-updated-on-save
Fix that a collection proxy could be cached before the save of the owner, resulting in an invalid proxy lacking the owner’s id
Conflicts:
activerecord/CHANGELOG.md
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
resulting in an invalid proxy lacking the owner’s id.
Absent this fix calls like: owner.association.update_all to behave unexpectedly because they try to act on association objects where
owner_id is null.
more evidence here: https://gist.github.com/Empact/5865555
```
Active Record 3.2.13
-- create_table(:firms, {:force=>true})
-> 0.1371s
-- create_table(:clients, {:force=>true})
-> 0.0005s
1 clients. 1 expected.
1 clients updated. 1 expected.
```
```
Active Record 4.0.0
-- create_table(:firms, {:force=>true})
-> 0.1606s
-- create_table(:clients, {:force=>true})
-> 0.0004s
1 clients. 1 expected.
0 clients updated. 1 expected.
```
|
| |
| |
| |
| | |
Print out a meaningful error when ActiveRecord::ReadOnlyRecord is raised
|
|\ \
| | |
| | |
| | | |
copy reflection_scopes’s unscoped value when building scope for preloading
|
| | | |
|
| | |
| | |
| | |
| | | |
This method is still used by `update_all`
|
| | |
| | |
| | |
| | |
| | | |
These appear to be implementation relics of times past. They duplicate
the logic in Relation, and are no longer used internally.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In practical terms, this allows serialized columns and tz aware columns
to be used in wheres that go through joins, where they previously would
not behave correctly. Internally, this removes 1/3 of the cases where we
rely on Arel to perform type casting for us.
There were two non-obvious changes required for this. `update_all` on
relation was merging its bind values with arel's in the wrong order.
Additionally, through associations were assuming there would be no bind
parameters in the preloader (presumably because the where would always
be part of a join)
[Melanie Gilman & Sean Griffin]
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The MySQLAdapter type map used the lowest priority for enum types.
This was the result of a recent refactoring and lead to some broken lookups
for enums with values that match other types. Like `8bit`.
This patch restores the priority to what we had before the refactoring.
/cc @sgrif
|
|\| |
| | |
| | |
| | | |
Raises ArgumentError when try to define a scope without a callable
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Use type column first in multi-column indexes
Conflicts:
activerecord/CHANGELOG.md
|
| |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
`add_reference` can very helpfully add a multi-column index when you use
it to add a polymorphic reference. However, the first column in the
index is the `id` column, which is less than ideal.
The [PostgreSQL docs][1] say:
> A multicolumn B-tree index can be used with query conditions that
> involve any subset of the index's columns, but the index is most
> efficient when there are constraints on the leading (leftmost)
> columns.
The [MySQL docs][2] say:
> MySQL can use multiple-column indexes for queries that test all the
> columns in the index, or queries that test just the first column, the
> first two columns, the first three columns, and so on. If you specify
> the columns in the right order in the index definition, a single
> composite index can speed up several kinds of queries on the same
> table.
In a polymorphic relationship, the type column is much more likely to be
useful as the first column in an index than the id column. That is, I'm
more likely to query on type without an id than I am to query on id
without a type.
[1]: http://www.postgresql.org/docs/9.3/static/indexes-multicolumn.html
[2]: http://dev.mysql.com/doc/refman/5.0/en/multiple-column-indexes.html
|
|/ / |
|
|\ \
| | |
| | |
| | | |
Message on AR::UnknownAttributeError should include the class name of a record
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This would be helpful if 2 models have an attribute that has a similar
name to the other. e.g:
before:
User.new(name: "Yuki Nishijima", projects_attributes: [name: "kaminari"])
# => ActiveRecord::UnknownAttributeError: unknown attribute: name
after:
User.new(name: "Yuki Nishijima", projects_attributes: [name: "kaminari"])
# => ActiveRecord::UnknownAttributeError: unknown attribute on User: name
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This would be helpful if 2 models have an attribute that has a similar
name to the other. e.g:
before:
User.new(name: "Yuki Nishijima", projects_attributes: [name: "kaminari"])
# => ActiveRecord::UnknownAttributeError: unknown attribute: name
after:
User.new(name: "Yuki Nishijima", projects_attributes: [name: "kaminari"])
# => ActiveRecord::UnknownAttributeError: unknown attribute on User: name
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
068f092ced8483e557725542dd919ab7c516e567 registered autosave callbacks
as `after_save` callbacks. This caused the regression described in #17209.
Autosave callbacks should be registered as `after_update` and
`after_create` callbacks, just like before.
This is a partial revert of 068f092ced8483e557725542dd919ab7c516e567.
Fixes #17209.
|
|/ |
|
|
|
|
| |
- middlware -> middleware
|
|
|
|
|
|
|
| |
Honoring an overidden `rack.test` allows testing closed connection between
multiple requests. This is useful if you're working on database resiliency, to
ensure the connection is in the expected state from one request to another on
the same worker.
|
|
|
|
| |
[ci skip]
|
|
|
|
|
|
| |
it doesn't work on SQLite3 since it doesn't support truncate, but that's
OK. If you call truncate on the connection, you're now bound to that
database (same as if you use hstore or any other db specific feature).
|
|\
| |
| |
| | |
ActiveRecord CHANGELOG improvements [skip ci]
|
|/ |
|
| |
|
|\
| |
| |
| |
| |
| |
| | |
Don't autosave unchanged has_one through records
Conflicts:
activerecord/CHANGELOG.md
|
| | |
|
| | |
|
| | |
|
|/
|
|
|
|
| |
Closes #16907.
[Matthew Draper & Yves Senn]
|