| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| |
| | |
wjessop/do_not_validate_non_dirty_association_targets
Don't validate non dirty association targets
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Fixes #36581.
This fixes an issue where validations would return differently when a previously saved invalid association was loaded between calls:
assert_equal true, squeak.valid?
assert_equal true, squeak.mouse.present?
assert_equal true, squeak.valid?
Here the second assert would return
Expected: true
Actual: false
Limiting validations to associations that would be normally saved (using autosave: true) due to changes means that loading invalid associated relations will not change the return value of the parent relations's `valid?` method.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- In 86620cc3aa8e2630bc8d934b1a86453276b9eee9, a change was made
on how we remove error duplication on a record for autosave
association
This fix has one caveat where validation having a `if` / `unless`
options passed as a proc would be considered different.
Example:
```ruby
class Book < ApplicationRecord
has_one :author
validates :title, presence: true, if -> { true }
validates :title, presence: true, if -> { true }
end
Book.new.valid? # false
Book.errors.full_messages # ["title can't be blank", "title can't be blank"]
```
While this example might sound strange, I think it's better to
ignore `AM::Validations` options (if, unless ...) when making the
comparison.
|
|\
| |
| |
| |
| | |
vishaltelangre/raise-record-invalid-when-associations-fail-to-save-due-to-uniqueness-failure
Fix: ActiveRecord::RecordInvalid is not raised when an associated record fails to #save! due to uniqueness validation failure
|
| |
| |
| |
| |
| |
| |
| |
| | |
fails to #save! due to uniqueness validation failure
Add tests
Fix tests failing due to introduction of uniquness rule added to Book model
|
|\ \
| | |
| | | |
Deduplicate various Active Record schema cache structures
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Real world database schemas contain a lot of duplicated data.
Some column names like `id`, `created_at` etc can easily be repeated
hundreds of times. Same for SqlTypeMetada, most database will contain
only a limited number of possible combinations.
This result in a lot of wasted memory.
The idea here is to make these data sctructures immutable, use a registry
to substitute similar instances with pre-existing ones.
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We sometimes say "✂️ newline after `private`" in a code review (e.g.
https://github.com/rails/rails/pull/18546#discussion_r23188776,
https://github.com/rails/rails/pull/34832#discussion_r244847195).
Now `Layout/EmptyLinesAroundAccessModifier` cop have new enforced style
`EnforcedStyle: only_before` (https://github.com/rubocop-hq/rubocop/pull/7059).
That cop and enforced style will reduce the our code review cost.
|
| | |
|
|/
|
|
| |
Fixes #34456.
|
| |
|
|
|
|
|
|
|
|
| |
* Make scope arity check consistent
* Add test for arity change
[Rob Trame + Rafael Mendonça França]
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a regression for #35864.
Usually, stashed joins (mainly eager loading) are performed as LEFT
JOINs.
But the case of merging joins/left_joins of different class, that
(stashed) joins are performed as the same `join_type` as the parent
context for now.
Since #35864, both (joins/left_joins) stashed joins might be contained
in `joins_values`, so each stashed joins should maintain its own
`join_type` context.
Fixes #36103.
|
|\
| |
| | |
Model error as object
|
| |
| |
| |
| | |
Revert some tests to ensure back compatibility
|
|\ \
| | |
| | |
| | |
| | |
| | | |
abhaynikam/35866-add-touch-option-for-has-one-association
Adds missing touch option to has_one association
|
| | | |
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
If we want to get alias resolved attribute finally, we can use
`attribute_alias` directly.
For that purpose, avoiding redundant `attribute_alias?` makes alias
attribute access 40% faster.
https://gist.github.com/kamipo/e427f080a27b46f50bc508fae3612a0e
Before (2c0729d8):
```
Warming up --------------------------------------
user['id'] 102.668k i/100ms
user['new_id'] 80.660k i/100ms
user['name'] 99.368k i/100ms
user['new_name'] 81.626k i/100ms
Calculating -------------------------------------
user['id'] 1.431M (± 4.0%) i/s - 7.187M in 5.031985s
user['new_id'] 1.042M (± 4.2%) i/s - 5.243M in 5.039858s
user['name'] 1.406M (± 5.6%) i/s - 7.055M in 5.036743s
user['new_name'] 1.074M (± 3.6%) i/s - 5.387M in 5.024152s
```
After (this change):
```
Warming up --------------------------------------
user['id'] 109.775k i/100ms
user['new_id'] 103.303k i/100ms
user['name'] 105.988k i/100ms
user['new_name'] 99.618k i/100ms
Calculating -------------------------------------
user['id'] 1.520M (± 6.7%) i/s - 7.574M in 5.011496s
user['new_id'] 1.485M (± 6.2%) i/s - 7.438M in 5.036252s
user['name'] 1.538M (± 5.4%) i/s - 7.737M in 5.049765s
user['new_name'] 1.516M (± 4.6%) i/s - 7.571M in 5.007293s
```
|
| |
| |
| |
| |
| |
| |
| |
| | |
If an association has a scope, `automatic_inverse_of` is to be disabled.
But extension block is obviously not a scope. It should not be regarded
as a scope.
Fixes #28806.
|
| |
| |
| |
| |
| |
| |
| |
| | |
This reverts commit b33ccaa6c335e2ce482c9de1aa05e4a612aa84bc.
That isn't hit by `git grep`, but actually used in meta-programming...
https://github.com/rails/rails/blob/b33ccaa6c335e2ce482c9de1aa05e4a612aa84bc/activerecord/test/cases/transactions_test.rb#L1020-L1028
|
| | |
|
|\ \
| | |
| | |
| | | |
Fix "autosave: true" on belongs_to of join model causes invalid records to be saved
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Use a variable local to the `save_collection_association` method in
`activerecord/lib/active_record/autosave_association.rb`, instead of an
instance variable.
Prior to this PR, when there was a circular series of `autosave: true`
associations, the callback for a `has_many` association was run while
another instance of the same callback on the same association hadn't
finished running. When control returned to the first instance of the
callback, the instance variable had changed, and subsequent associated
records weren't saved correctly. Specifically, the ID field for the
`belongs_to` corresponding to the `has_many` was `nil`.
Remove unnecessary test and comments.
Fixes #28080.
|
| |/
|/|
| |
| | |
`values[:extending]` includes `NullRelation` if `null_relation?`.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This patch has two main portions:
1. Add SQL comment support to Arel via Arel::Nodes::Comment.
2. Implement a Relation#annotate method on top of that.
== Adding SQL comment support
Adds a new Arel::Nodes::Comment node that represents an optional SQL
comment and teachers the relevant visitors how to handle it.
Comment nodes may be added to the basic CRUD statement nodes and set
through any of the four (Select|Insert|Update|Delete)Manager objects.
For example:
manager = Arel::UpdateManager.new
manager.table table
manager.comment("annotation")
manager.to_sql # UPDATE "users" /* annotation */
This new node type will be used by ActiveRecord::Relation to enable
query annotation via SQL comments.
== Implementing the Relation#annotate method
Implements `ActiveRecord::Relation#annotate`, which accepts a comment
string that will be appeneded to any queries generated by the relation.
Some examples:
relation = Post.where(id: 123).annotate("metadata string")
relation.first
# SELECT "posts".* FROM "posts" WHERE "posts"."id" = 123
# LIMIT 1 /* metadata string */
class Tag < ActiveRecord::Base
scope :foo_annotated, -> { annotate("foo") }
end
Tag.foo_annotated.annotate("bar").first
# SELECT "tags".* FROM "tags" LIMIT 1 /* foo */ /* bar */
Also wires up the plumbing so this works with `#update_all` and
`#delete_all` as well.
This feature is useful for instrumentation and general analysis of
queries generated at runtime.
|
| | |
|
| |
| |
| |
| |
| | |
This was using a model without a default scope what made the test don't
break anymore if the code is removed.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This fixes both #34555 and #34738.
Revert "Merge pull request #34900 from gmcgibbon/fix_test_find_only_some_columns"
This reverts commit ff807f823b869d3491935a096183ee2bebd58e7b, reversing
changes made to 9f1a07af0499080c9fd8815705a03a4c7e8fb506.
Revert "Merge pull request #34560 from gmcgibbon/fix_decorate_leak_on_serial_attr_test"
This reverts commit bd62389307e138ee0f274a9d62697567a3334ea0, reversing
changes made to ec66c6a2fa4ee200259341a18ecd96310f388ba3.
Revert "Fix unstable `test_serialized_attribute_works_under_concurrent_initial_access` test"
This reverts commit 65c4b1b50df3fa59198de2d45d1f54b61ecc7864.
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| | |
When the middle association doesn't have any records and the inner
association is not an empty scope the owner will be `nil` so we can't
try to reset the inverse association.
|
|\ \
| | |
| | | |
Replaced usage of where.delete/destroy_all with delete/destroy_by
|
| | | |
|
|\ \ \
| |/ /
|/| | |
Fix reset of the source association when through association is loaded
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The special case happens when through association has a custom scope
that is applied to the source association when loading.
In this case, the soucre association would need to be reset after
main association is loaded. See tests.
The special case exists when a through association has
|
| | |
| | |
| | |
| | |
| | |
| | | |
This fixes a bug that the `foreign_key` and the `foreign_type` are
separated as different table conditions if a polymorphic association has
a scope that joins another tables.
|
| | |
| | |
| | |
| | | |
This follows up 0ee96d13de29680e148ccb8e5b68025f29fd091c.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
kamipo/fix_leaking_scope_on_relation_create"
This reverts commit b67d5c6dedbf033515a96a95d24d085bf99a0d07, reversing
changes made to 2e018361c7c51e36d1d98bf770b7456d78dee68b.
Reason: #35186 may cause that silently leaking information when people
upgrade the app.
We need deprecation first before making this.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
methods"
This reverts #32380, since this may cause that silently leaking
information when people upgrade the app.
We need deprecation first before making this.
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| | |
Currently custom attributes are always qualified by the table name in
the generated SQL wrongly even if the table doesn't have the named
column, it would cause an invalid SQL error.
Custom attributes should only be qualified if the table has the same
named column.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
callbacks
`relation.create` populates scope attributes to new record by `scoping`,
it is necessary to assign the scope attributes to the record and to find
STI subclass from the scope attributes.
But the effect of `scoping` is class global, it was caused undesired
behavior that pollute all class level querying methods in initialization
block and callbacks (`after_initialize`, `before_validation`,
`before_save`, etc), which are user provided code.
To avoid the leaking scope issue, restore the original current scope
before initialization block and callbacks are invoked.
Fixes #9894.
Fixes #17577.
Closes #31526.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Active Record uses `scoping` to delegate to named scopes from relations
for propagating the chaining source scope. It was needed to restore the
source scope in named scopes, but it was caused undesired behavior that
pollute all class level querying methods.
Example:
```ruby
class Topic < ActiveRecord::Base
scope :toplevel, -> { where(parent_id: nil) }
scope :children, -> { where.not(parent_id: nil) }
scope :has_children, -> { where(id: Topic.children.select(:parent_id)) }
end
# Works as expected.
Topic.toplevel.where(id: Topic.children.select(:parent_id))
# Doesn't work due to leaking `toplevel` to `Topic.children`.
Topic.toplevel.has_children
```
Since #29301, the receiver in named scopes has changed from the model
class to the chaining source scope, so the polluting class level
querying methods is no longer required for that purpose.
Fixes #14003.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
#33729 affected the behavior of the has_many through record creation.
Since #33729, the intermediate reflection of simple has_many through
association has `inverse_of` to the association, it causes extra through
record creation, the extra through record required valid before the
association record is saved.
https://github.com/rails/rails/blob/23125378673bcc606b274027666a126573e136f8/activerecord/lib/active_record/associations/has_many_through_association.rb#L95-L102
I think that #33729 need to more work to care about has_many through
association, that PR should be reverted to not break existing apps.
|
| |
| |
| |
| |
| |
| |
| |
| | |
- Remove `fragment_cache_key` helper declaration.
It was removed in e70d3df7c9b05c129b0fdcca57f66eca316c5cfc
- Remove `by_private_lifo`.
It is unused since a7becf147afc85c354e5cfa519911a948d25fc4d
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Since 31ffbf8d, finder methods no longer raise `RangeError`. So
`StatementCache#execute` is the only place to raise the exception for
finder queries.
`StatementCache` is used for simple equality queries in the codebase.
This means that if `StatementCache#execute` raises `RangeError`, the
result could always be regarded as empty.
So `StatementCache#execute` just return nil in that range error case,
and treat that as empty in the caller side, then we can avoid catching
the exception in much places.
|
| |
| |
| |
| |
| |
| | |
(#28078)
This PR addresses the issue described in #28025. On `dependent: :nullify` strategy only the foreign key of the relation is nullified. However on polymorphic associations the `*_type` column is not nullified leaving the record with a NULL `*_id` but the `*_type` column is present.
|
| |
| |
| |
| |
| | |
Otherwise `save` method would raise the `ReadOnlyError` against `BEGIN`
and `ROLLBACK` queries.
|
|\ \
| | |
| | | |
Fix the scoping with query methods in the scope block
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
|\ \ \
| |/ /
|/| | |
Additional types of ResultSet should not contain keys of #attributes_to_define_after_schema_loads
|