| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This is to simplify the association API, as you can call `reload` on the
association proxy or the parent object to get the same result.
For collection association, you can call `#reload` on association proxy
to force a reload:
@user.posts.reload # Instead of @user.posts(true)
For singular association, you can call `#reload` on the parent object to
clear its association cache then call the association method:
@user.reload.profile # Instead of @user.profile(true)
Passing a truthy argument to force association to reload will be removed
in Rails 5.1.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The concurrent-ruby gem is a toolset containing many concurrency
utilities. Many of these utilities include runtime-specific
optimizations when possible. Rather than clutter the Rails codebase with
concurrency utilities separate from the core task, such tools can be
superseded by similar tools in the more specialized gem. This commit
replaces `ActiveSupport::Concurrency::Latch` with
`Concurrent::CountDownLatch`, which is functionally equivalent.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The changes introduced to through associations in c80487eb were quite
interesting. Changing `relation.merge!(scope)` to `relation =
relation.merge(scope)` should in theory never cause any changes in
behavior. The subtle breakage led to a surprising conclusion.
The old code wasn't doing anything! Since `merge!` calls
`instance_exec` when given a proc, and most scopes will look something
like `has_many :foos, -> { where(foo: :bar) }`, if we're not capturing
the return value, it's a no-op. However, removing the `merge` causes
`unscope` to break.
While we're merging in the rest of the chain elsewhere, we were never
merging in `unscope` values, causing a breakage on associations where a
default scope was being unscoped in an association scope (yuk!). This is
subtly related to #20722, since it appears we were previously relying on
this mutability.
Fixes #20721.
Fixes #20727.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Closes #20743.
The task `db:_dump` now only dumps the schema if
`ActiveRecord::Base.dump_schema_after_migration` is true. This has
effects:
- `db:migrate:up`
- `db:migrate:down`
- `db:forward`
- `db:rollback`
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Passing `:from` and `:to` to `change_column_default` makes this command
reversible as user has defined its previous state.
So, instead of having the migration command as:
change_column_default(:posts, :state, "draft")
They can write it as:
change_column_default(:posts, :state, from: nil, to: "draft")
|
|\ \
| | |
| | |
| | | |
Fix `undefined method uncached` for polymorphic belongs_to #20426
|
|\ \ \
| | | |
| | | |
| | | | |
thrown ActiveRecord::AssociationTypeMismatch when assigning a wrong value for a namespaced association
|
|/ / /
| | |
| | |
| | |
| | | |
for a namespaced association
fixes #20541
|
| | |
| | |
| | |
| | | |
Associated objects that were marked for destruction are considered absent.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
After discussing, we've decided it makes more sense to include it. We're
already forwarding every conflicting method to `to_a`, and there's no
conflation of concerns. `Enumerable` has no mutating methods, and it
just allows us to simplify the code. No existing methods will have a
change in behavior. Un-overridden Enumerable methods will simply
delegate to `each`.
[Sean Griffin & bogdan]
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This matches our behavior in other cases where useful enumerable methods
might have a different definition in `Relation`. Wanting to actually
enumerate over the records in this case is completely reasonable, and
wanting `.sum` is reasonable for the same reason it is on `Enumerable`
in the first place.
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Let WITH (CTE) queries be explainable
Conflicts:
activerecord/CHANGELOG.md
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This used to raise a `IrreversibleMigration` error (since #10437).
However since `remove_index :table, :column` is probably the most basic
use-case we should make it reversible again.
Conflicts:
activerecord/CHANGELOG.md
|
| |/ /
|/| | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If a getter has side effects on the DB, `changes_applied` will be called
twice. The second time will try and remove the changed attributes cache,
and will crash because it's already been unset. This also demonstrates
that we shouldn't assume that calling getters won't change the value of
`changed_attributes`, and we need to clear the cache if an attribute is
modified.
Fixes #20531.
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Make remove_foreign_key reversible
Conflicts:
activerecord/CHANGELOG.md
|
| | | | |
|
|/ / /
| | |
| | |
| | | |
Fixes #17511 and #17415
|
| | |
| | |
| | |
| | | |
[Sean Griffin & jmondo]
|
| |/
|/|
| |
| |
| |
| |
| |
| |
| | |
If the subtype provides custom schema dumping behavior, we need to defer
to it. We purposely choose not to handle any values other than an array
(which technically should only ever be `nil`, but I'd rather code
defensively here).
Fixes #20515.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This introduces a deprecation cycle to change the behavior of the
default point type in the PostgreSQL adapter. The old behavior will
continue to be available for the immediate future as `:legacy_point`.
The current behavior of returning an `Array` causes several problems,
the most significant of which is that we cannot differentiate between an
array of points, and a point itself in the case of a column with the
`point[]` type.
The attributes API gives us a reasonable way to have a proper
deprecation cycle for this change, so let's take advantage of it. If we
like this change, we can also add proper support for the other geometric
types (line, lseg, box, path, polygon, and circle), all of which are
just aliases for string today.
Fixes #20441
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Our general contract in Active Record is that strings are assumed to be
SQL literals, and symbols are assumed to reference a column. If a from
clause is given, we shouldn't include the table name, but we should
still quote the value as if it were a column.
Upon fixing this, the tests were still failing on SQLite. This was
because the column name being returned by the query was `"\"join\""`
instead of `"join"`. This is actually a bug in SQLite that was fixed a
long time ago, but I was using the version of SQLite included by OS X
which has this bug. Since I'm guessing this will be a common case for
contributors, I also added an explicit check with a more helpful error
message.
Fixes #20360
|
| | |
|
|/ |
|
| |
|
| |
|
|\
| |
| |
| | |
Allow the use of symbols or strings to specify enum values in test fixtures
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Currently, values for columns backing Active Record enums must be
specified as integers in test fixtures:
awdr:
title: "Agile Web Development with Rails"
status: 2
rfr:
title: "Ruby for Rails"
status: <%= Book.statuses[:proposed] %>
This is potentially confusing, since enum values are typically
specified as symbols or strings in application code. To resolve the
confusion, this change permits the use of symbols or strings to specify
enum values:
awdr:
status: :published
It is compatible with fixtures that specify enum values as integers.
|
|\ \
| |/
|/|
| | |
Cause ActiveRecord::Base::reload to also ignore the QueryCache.
|
|\ \
| | |
| | |
| | | |
Changed mysqldump to include sprocs and functions
|
| | | |
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| | |
See #9683 for the reasons we switched to `distinct`.
Here is the discussion that triggered the actual deprecation #20198.
`uniq`, `uniq!` and `uniq_value` are still around.
They will be removed in the next minor release after Rails 5.
|
| | |
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | | |
https://github.com/agrobbin/rails into agrobbin-sti-subclass-from-attributes
Conflicts:
activerecord/CHANGELOG.md
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
If your STI class looks like this:
```ruby
class Company < ActiveRecord::Base
self.store_full_sti_class = false
class GoodCo < Company
end
class BadCo < Company
end
end
```
The expectation (which is valid) is that the `type` in the database is saved as
`GoodCo` or `BadCo`. However, another expectation should be that setting `type`
to `GoodCo` would correctly instantiate the object as a `Company::GoodCo`. That
second expectation is what this should fix.
|
|/ /
| |
| |
| | |
db:structure dump and load
|
|\ \
| | |
| | |
| | | |
Dump indexes in `create_table` instead of `add_index`
|
| | |
| | |
| | |
| | |
| | | |
If the adapter supports indexes in create table, generated SQL is
slightly more efficient.
|
|\ \ \
| | | |
| | | |
| | | | |
Correctly dump `:options` on `create_table` for MySQL
|
| |/ / |
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| | |
Example:
create_table :foos do |t|
t.string :string_en, collation: 'en_US.UTF-8'
t.text :text_ja, collation: 'ja_JP.UTF-8'
end
|
| | |
|
|\ \
| | |
| | |
| | | |
Fix unscope for less than
|
|\ \ \
| | | |
| | | |
| | | | |
Raise ArgumentError when find_by receives no arguments
|
| |_|/
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
calebthompson/dont-rely-on-environment-task-for-schema-load"
This reverts commit 08ff4ccbbb3fb143a02e6752efb974a4bcfcd3bb, reversing
changes made to 6c9ed6dbc62450cdb87559afd15798305e069146.
Caused by #17920.
Closes #19545.
This patch introduced regressions because initializers were no longer
loaded. Specifically missing inflections result in broken restores of
the database.
|
|\ \ \
| | | |
| | | |
| | | | |
Fix missing index when using timestamps with index
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The `index` option used with `timestamps` should be passed to both
`column` definitions for `created_at` and `updated_at` rather than just
the first.
This was happening because `Hash#delete` is used to extract the `index`
option passed to `timestamps`, thereby mutating the `options` hash
in-place. Now take a copy of the `options` before deleting so that the
original is not modified.
|