| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | |
|
| | |
|
| |
| |
| |
| |
| | |
NumericalityValidator#validate_each is never called when allow_nil is true and
the value is nil because it is already skipped in EachValidator#validate.
|
| |
| |
| | |
This fixes a copy-and-paste-issue slipped in by #18996
|
| |
| |
| |
| | |
Hash syntax auto-correcting breaks alignments. 411ccbdab2608c62aabdb320d52cb02d446bb39c
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
A few have been left for aesthetic reasons, but have made a pass
and removed most of them.
Note that if the method `foo` returns an array, `foo << 1`
is a regular push, nothing to do with assignments, so
no self required.
|
| |
| |
| |
| | |
Some case expressions remain, need to think about those ones.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
| | |
|
| |
| |
| |
| | |
add documentation of the behaviors of type coercion at the class level
|
|\ \
| | |
| | | |
Fix `Type::Date#serialize` to return a date object correctly
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Currently `Type::Date#serialize` does not cast a value to a date object.
It should be cast to a date object for finding by date column correctly
working.
Fixes #25354.
|
| | |
| | |
| | |
| | |
| | | |
Fix a tiny typo and vertical-align some return results in the
ActiveModel::Errors documentation.
|
| | | |
|
|/ / |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
We now use default procs inside of the errors object, which gets
included by default when marshaling anything that includes
`ActiveModel::Validations`. This means that Active Record objects cannot
be marshalled. We strip and apply the default proc ourselves. This will
ensure the objects are YAML serializable as well, since YAML falls back
to marshal implementations now. This is less important, however, as the
errors aren't included when dumping Active Record objects.
This commit does not include a changelog entry, as 5.0 is still in RC
status at the time of writing, and 5.0.0 will not release with the bug
this fixes.
Fixes #25165
|
| |
| |
| |
| |
| |
| |
| |
| | |
Ruby 2.4 unifies Fixnum and Bignum into Integer: https://bugs.ruby-lang.org/issues/12005
* Forward compat with new unified Integer class in Ruby 2.4+.
* Backward compat with separate Fixnum/Bignum in Ruby 2.2 & 2.3.
* Drops needless Fixnum distinction in docs, preferring Integer.
|
| | |
|
|\ \
| | |
| | |
| | |
| | | |
Conflicts:
guides/source/configuring.md
|
| | |
| | |
| | |
| | | |
[ci skip]
|
| | |
| | |
| | |
| | | |
human readable form [ci skip]
|
| | | |
|
| | | |
|
| |/
|/|
| |
| |
| |
| | |
The should make it easier for apps to rescue ActiveModel specific
errors without the need to wrap all method calls with a generic
rescue RangeError.
|
|/
|
|
|
|
| |
Closes #24766, #24767
Signed-off-by: Jeremy Daer <jeremydaer@gmail.com>
|
| |
|
| |
|
| |
|
| |
|
| |
|
|\
| |
| | |
speed up ActiveModel::Dirty#attribute_changed?
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Benchmark results:
Warming up --------------------------------------
old code 32.176k i/100ms
new code 34.837k i/100ms
Calculating -------------------------------------
old code 1.595M (± 3.5%) i/s - 7.947M
new code 1.942M (± 3.9%) i/s - 9.685M
|
|/
|
|
|
|
|
|
|
|
| |
- we are ending sentences properly
- fixing of space issues
- fixed continuity issues in some sentences.
Reverts https://github.com/rails/rails/commit/8fc97d198ef31c1d7a4b9b849b96fc08a667fb02 .
This change reverts making sure we add '.' at end of deprecation sentences.
This is to keep sentences within Rails itself consistent and with a '.' at the end.
|
| |
|
|
|
|
|
|
|
|
|
| |
- Pass object to I18n helper so that when calling message proc, it will
pass that object as argument to the proc and we can generate custom
error messages based on current record being validated.
- Based on https://github.com/rails/rails/issues/856.
[Łukasz Bandzarewicz, Prathamesh Sonpatki]
|
|\
| |
| | |
Do not create a hash key when calling ActiveModel::Errors#include?
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
From: https://github.com/rails/rails/issues/24279
Problem:
By doing `record.errors.include? :foo`, it adds a new key to the
@messages hash that defaults to an empty array.
This happens because of a combination of these 2 commits:
https://github.com/rails/rails/commit/b97035df64f5b2f912425c4a7fcb6e6bb3ddab8d
(Added in Rails 4.1)
and
https://github.com/rails/rails/commit/6ec8ba16d85d5feaccb993c9756c1edcbbf0ba13#diff-fdcf8b65b5fb954372c6fe1ddf284c78R76
(Rails 5.0)
By adding the default proc that returns an array for non-existing keys,
ruby adds that key to the hash.
Solution:
Change `#include?` to check with `has_key?` and then check if that value is
`present?`.
Add test case for ActiveModels::Errors#include?
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Since precision is always larger than scale, it can actually change
rounding behavior. Given a precision of 5 and a scale of 3, when you
apply the precision of 5 to `1.25047`, the result is `1.2505`, which
when the scale is applied would be `1.251` instead of the expected
`1.250`.
This issue appears to only occur with floats, as scale doesn't apply to
other numeric types, and the bigdecimal constructor actually ignores
precision entirely when working with strings. There's no way we could
handle this for the "unknown object which responds to `to_d`" case, as
we can't assume an interface for applying the scale.
Fixes #24235
|
|/ |
|
|
|
|
| |
Follow up to #24079
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|\
| |
| | |
Remove unused parameter from method
|
| |
| |
| |
| |
| |
| | |
The `attribute` parameter is not used inside the `normalize_detail`
method. This does not need to go through a deprecation cycle, since the
method is private.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
| |
|