| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
| |
Follow up #33394.
#33394 only fixes the case of scoping with klass methods in the scope
block which invokes `klass.all`.
Query methods in the scope block also need to invoke `klass.all` to be
affected by the scoping.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
In order to avoid double assignments of nested_attributes for `has_many`
relations during record initialization, nested_attributes in `create_with`
should not be passed into `klass.new` and have them populate during
`initialize_internals_callback` with scope attributes.
However, `create_with` keys should always have precedence over where
clauses, so if there are same keys in both `create_with` and
`where_values_hash`, the value in `create_with` should be the one that's
used.
|
|
|
|
|
|
|
|
|
|
| |
Since #29301, delegating to klass methods in the `scope` block would
cause extra scoping by the receiver itself. The extra scoping would
always override intermediate scoping like `unscoped` and caused the
regression #33387. To keep the original scoping behavior, should avoid
the extra scoping in the `scope` block.
Fixes #33387.
|
| |
|
| |
|
|
|
|
|
| |
This autocorrects the violations after adding a custom cop in
3305c78dcd.
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| |
| | |
Allow unscoping of left_outer_joins
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Due to inconsistent behavior when chaining scopes and one scope named after a Relation method
Validation code added in 2 places:
- scope, to prevent problematic scope names.
- enum, cause it tries to auto define scope.
|
|\ \
| | |
| | | |
Do not use `Arel.star` when `ignored_columns`
|
| | | |
|
|/ /
| |
| |
| |
| |
| |
| |
| | |
A relation includes `klass`, so it can not be used as it is if current
class is different from `current_scope.klass`. It should be created new
relation by current class to respect the klass and STI constraint.
Fixes #17603.
Fixes #23576.
|
| |
| |
| |
| | |
https://travis-ci.org/rails/rails/jobs/263617099#L769-L775
|
|\ \ |
|
| | | |
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Since 5c71000, it has lost to be able to unscope `default_scope` in STI
associations. This change will use `.empty_scope?` instead of
`.values.empty?` to regard as an empty scope if only have
`type_condition`.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This change was introduced by #18109. The intent of that change was to
specifically apply `unscoped`, not to allow all changes to
`current_scope` to affect the join. The idea of allowing `current_scope`
to affect joins is interesting and potentially more consistent, but has
sever problems associated with it. The fact that we're specifically
stripping out joins indicates one such problem (and potentially leads to
invalid queries).
Ultimately it's difficult to reason about what `Posts.joins(:users)`
actually means if it's affected by `User.current_scope`, and it's
difficult to specifically control what does or doesn't get added. If we
were starting from scratch, I don't think I'd have `joins` be affected
by `default_scope` either, but that's too big of a breaking change to
make at this point.
With this change, we no longer apply `current_scope` when bringing in
joins, with the singular exception of the motivating use case which
introduced this bug, which is providing a way to *opt-out* of having the
default scope apply to joins.
Fixes #29338.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We have some indentation cops. But now there is a little inconsistent
params indentations. Enable `Layout/FirstParameterIndentation` cop to
prevent newly inconsistent indentation added and auto-correct to
existing violations.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is related with #27680.
Since `where_values_hash` keys constructed by `where` are string, so we
need `stringify_keys` to `create_with_value` before merging it.
|
|\| | |
|
| | |
| | |
| | |
| | |
| | | |
This reverts commit 3420a14590c0e6915d8b6c242887f74adb4120f9, reversing
changes made to afb66a5a598ce4ac74ad84b125a5abf046dcf5aa.
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This regression was caused by #23004.
If STI subclass is using scoping in parent class scoping,
`current_scope` in subclass is never restored.
I fixed to restore `current_scope` to previous value correctly.
|
|\| | |
|
| | | |
|
|\| | |
|
| | |
| | |
| | |
| | | |
Follow up of #25702.
|
| | |
| | |
| | |
| | |
| | | |
This change reverted in eac6f369 but it is needed for data integrity.
See #25328.
|
|/ /
| |
| |
| |
| |
| | |
`DefaultScopingWithThreadTest` expects that there are two or more of
`developers` data, but have not created data in the test.
Therefore, tests may fail depending on execution order.
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
mtsmfm/disable-referential-integrity-without-superuser-privilege-take-2"
This reverts commit c1faca6333abe4b938b98fedc8d1f47b88209ecf, reversing
changes made to 8c658a0ecc7f2b5fc015d424baf9edf6f3eb2b0b.
See https://github.com/rails/rails/pull/27636#issuecomment-297534129
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
privileges (take 2)
Re-create https://github.com/rails/rails/pull/21233
eeac6151a5 was reverted (127509c071b4) because it breaks tests.
----------------
ref: 72c1557254
- We must use `authors` fixture with `author_addresses` because of its foreign key constraint.
- Tests require PostgreSQL >= 9.4.2 because it had a bug about `ALTER CONSTRAINTS` and fixed in 9.4.2.
|
| |
| |
| |
| |
| |
| |
| | |
Since b644964b `ActiveRecord::Relation` includes `Enumerable` so
delegating `collect`, `all?`, and `include?` are also unneeded.
`collect` without block returns `Enumerable` without preloading by that.
We should use `load` rather than `collect` for force loading.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we run only following tests:
- test/cases/scoping/default_scoping_test.rb
- test/cases/associations_test.rb
```
$ cat Rakefile.test
require "rake/testtask"
ENV["ARCONN"] = "postgresql"
Rake::TestTask.new do |t|
t.libs << "test"
t.test_files = %w(
test/cases/scoping/default_scoping_test.rb
test/cases/associations_test.rb
)
end
```
a test will fail:
```
$ bundle exec rake test -f Rakefile.test
/app/activesupport/lib/active_support/core_ext/enumerable.rb:20: warning: method redefined; discarding old sum
Using postgresql
Run options: --seed 11830
# Running:
.........................................................................................F................
Finished in 6.939055s, 15.2759 runs/s, 27.9577 assertions/s.
1) Failure:
AssociationProxyTest#test_save_on_parent_saves_children [/app/activerecord/test/cases/associations_test.rb:185]:
Expected: 1
Actual: 2
106 runs, 194 assertions, 1 failures, 0 errors, 0 skips
rake aborted!
Command failed with status (1)
/usr/local/bin/bundle:22:in `load'
/usr/local/bin/bundle:22:in `<main>'
Tasks: TOP => test
(See full trace by running task with --trace)
```
In #28083, change `self.use_transactional_tests` to `false`
but we forget to clean-up fixture.
However we don't have to disable transaction except a few tests.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This ensures multiple threads inside a transactional test to see consistent
database state.
When a system test starts Puma spins up one thread and Capybara spins up
another thread. Because of this when tests are run the database cannot
see what was inserted into the database on teardown. This is because
there are two threads using two different connections.
This change uses the statement cache to lock the threads to using a
single connection ID instead of each not being able to see each other.
This code only runs in the fixture setup and teardown so it does not
affect real production databases.
When a transaction is opened we set `lock_thread` to `Thread.current` so
we can keep track of which connection the thread is using. When we
rollback the transaction we unlock the thread and then there will be no
left-over data in the database because the transaction will roll back
the correct connections.
[ Eileen M. Uchitelle, Matthew Draper ]
|
|
|
|
|
|
|
|
|
|
| |
mtsmfm/disable-referential-integrity-without-superuser-privileges"
This reverts commit eeac6151a55cb7d5f799e1ae33aa64a839cbc3aa, reversing
changes made to 5c40239d3104543e70508360d27584a3e4dc5baf.
Reason: Broke the isolated tests.
https://travis-ci.org/rails/rails/builds/188721346
|
|\
| |
| |
| |
| | |
mtsmfm/disable-referential-integrity-without-superuser-privileges
Use `SET CONSTRAINTS` for `disable_referential_integrity` without superuser privileges
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
privileges
ref: 72c1557254
- We must use `authors` fixture with `author_addresses` because of its foreign key constraint.
- Tests require PostgreSQL >= 9.4.2 because it had a bug about `ALTER CONSTRAINTS` and fixed in 9.4.2.
|
| | |
|
|/ |
|
| |
|
|
|
|
|
|
| |
Regexp#match? should be considered to be part of the Ruby core library. We are
emulating it for < 2.4, but not having to require the extension is part of the
illusion of the emulation.
|
|
|
|
|
|
| |
assert [1, 3].includes?(2) fails with unhelpful "Asserting failed" message
assert_includes [1, 3], 2 fails with "Expected [1, 3] to include 2" which makes it easier to debug and more obvious what went wrong
|