| Commit message (Collapse) | Author | Age | Files | Lines |
|\
| |
| |
| | |
Avoid a string value truncation in uniqueness validation
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In MySQL, PostgreSQL, Oracle and SQLServer, a value over the limit
cannot be inserted or updated (See #23522).
In SQLite3, a value is inserted or updated regardless of the limit.
We should avoid a string value truncation in uniqueness validation.
|
| |
| |
| |
| | |
Currently use minitest mock, mocha is not used.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
record.id_was is nil in after_create/after_save, so we should use
id in these cases.
While this logic feels incomplete, the existing update_record uses the same
logic:
https://github.com/rails/rails/blob/2fda4e0874a97a76107ab9e88305169f2c625933/activerecord/lib/active_record/relation.rb#L83
This logic was originally added for a similar problem:
updates not working with after_create hook.
See: 482f8c15b1d699c95bfbc3d836f674a09c0d9031
Followup to #23581
Fixes #23844
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In order to fix issue #17621 we added a check to validations that
determined if a record should be validated. Based on the existing tests
and behavior we wanted we determined the best way to do that was by
checking if `!record.peristed? || record.changed? || record.marked_for_destruction?`
This change didn't make it into a release until now. When #23790 was
opened we realized that `valid?` and `invalid?` were broken and did not
work on persisted records because of the `!record.persisted?`.
While there is still a bug that #17621 brought up, this change was too
drastic and should not be a RC blocker. I will work on fixing this so
that we don't break `valid?` but also aren't validating parent records
through child records if that parent record is validate false. This
change removes the code changes to validate and the corresponding tests.
It adds tests for two of the bugs found since Rails 5 beta2 release.
Fixes #17621
|
|\ \
| | |
| | | |
Fix issue #23625
|
| |/
| |
| |
| |
| |
| | |
This resolves a bug where if the primary key used is not `id` (ex:
`uuid`), and has a `validates_uniqueness_of` in the model, a uniqueness error
would be raised. This is a partial revert of commit `119b9181ece399c67213543fb5227b82688b536f`, which introduced this behavior.
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes #23645
When you're using an `attr_accessor` for a record instead of an
attribute in the database there's no way for the record to know if it
has `changed?` unless you tell it `attribute_will_change!("attribute")`.
The change made in 27aa4dd updated validations to check if a record was
`changed?` or `marked_for_destruction?` or not `persisted?`. It did not
take into account virtual attributes that do not affect the model's
dirty status.
The only way to fix this is to always validate the record if the
attribute does not belong to the set of attributes the record expects
(in `record.attributes`) because virtual attributes will not be in that
hash.
I think we should consider deprecating this particular behavior in the
future and requiring that the user mark the record dirty by noting that
the virtual attribute will change. Unfortunately this isn't easy because
we have no way of knowing that you did the "right thing" in your
application by marking it dirty and will get the deprecation warning
even if you are doing the correct thing.
For now this restores expected behavior when using a virtual attribute
by always validating the record, as well as adds tests for this case.
I was going to add the `!record.attributes.include?(attribute)` to the
`should_validate?` method but `uniqueness` cannot validate a virtual
attribute with nothing to hold on to the attribute. Because of this
`should_validate?` was about to become a very messy method so I decided
to split them up so we can handle it specifically for each case.
|
|
|
|
|
|
|
| |
When changing the PK for a record which has a uniqueness validation on
some other attribute, Active Record should exclude itself from the
validation based on the PK value stored on the DB (id_was) instead of
its new value (id).
|
|
|
|
|
|
| |
Skipping `marked_for_destruction?` when the associated object does not responds
to it make easier to validate virtual associations built on top of Active Model
objects and/or serialized objects that implement a `valid?` instance method.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Closes #21304.
While we can validate uniqueness for record without primary key on
creation, there is no way to exclude the current record when
updating. (The update itself will need a primary key to work correctly).
|
|
|
|
|
|
| |
This is an alternate implementation of #20966.
[Sean Griffin & presskey]
|
|
|
|
| |
Associated objects that were marked for destruction are considered absent.
|
|\ |
|
|/ |
|
| |
|
|
|
|
| |
onwards.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes #17621. This 5 year old (or older) issue causes validations to fire
when a parent record has `validate: false` option and a child record is
saved. It's not the responsibility of the model to validate an
associated object unless the object was created or modified by the
parent.
Clean up tests related to validations
`assert_nothing_raised` is not benefiting us in these tests
Corrected spelling of "respects"
It's better to use `assert_not_operator` over `assert !r.valid`
|
|
|
|
|
|
|
|
| |
Closes #7247.
Conflicts:
activerecord/CHANGELOG.md
activerecord/test/models/owner.rb
|
| |
|
| |
|
|
|
|
| |
Or some tests fail when run in random order
|
| |
|
|
|
|
|
| |
Conflicts:
activerecord/test/cases/validations/association_validation_test.rb
|
|
|
|
|
|
|
|
| |
Follow-Up to https://github.com/rails/rails/pull/14348
Ensure that SQLCounter.clear_log is called after each test.
This is a step to prevent side effects when running tests. This will allow us to run them in random order.
|
|
|
|
| |
please pass the id of the AR object by calling `.id` on the model first.
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
laurocaetano/fix-uniqueness-validation-for-aliased-attribute
Fix bug when validating the uniqueness of an aliased attribute.
Conflicts:
activerecord/CHANGELOG.md
|
| |
|
|
|
|
| |
test/cases/validations/i18n_generate_message_validation_test.rb and test/cases/validations/uniqueness_validation_test.rb
|
|
|
|
|
|
|
| |
We can conditional define the tests depending on the adapter or
connection.
Lets keep the skip for fail tests that need to be fixed.
|
| |
|
|
|
|
|
|
|
|
| |
This behaviour doesn't actually make sense, the context of
the child should not be affected by the parent. See #10492.
This reverts commit 5f8274efe128ffeec8fa3179460f5167a078f007, reversing
changes made to 81e837e810460d066a2e5fc5a795366ec8ab2313.
|
| |
|
| |
|
|
|
|
| |
Take the opportunity to showcase where.not.
|
|
|
|
|
| |
This is a follow up to #5321 and follows the general direction in
AR to make things lazy evaluated.
|
|
|
|
| |
Fixes: #8075.
|
|
|
|
|
|
| |
activerecord scope.
Related with 5341b84936d93ec90e6252af437a3871101c115a
|
|
|
|
|
|
| |
Moved activerecord.errors.messages.taken to errors.messages.taken so that translations for, e.g., errors.attributes.email.taken don't get overridden.
Test that the translation for 'taken' can be overridden
|
|
|
|
| |
Would incorrectly add duplicated errors when the association was blank. Bug introduced in 1fab518c6a75dac5773654646eb724a59741bc13.
|
| |
|
| |
|
|\
| |
| | |
Validates_presence_of associated object marked for destruction
|