| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
| |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
|
|
|
| |
Fixes #25410.
|
|
|
|
|
|
|
|
|
| |
- The `Project` model should have been removed in 468939297db91f8e595a93c94a16e23b26eee61a.
- The superfluous require was added in 605c6455ac722ed9679e17458a47cc649cdedab0.
Closes #25215
Signed-off-by: Jeremy Daer <jeremydaer@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|\
| |
| | |
Followup of #18322
|
| |
| |
| |
| | |
Mirror the documented new behavior of including details, when performing errors test.
|
| | |
|
|/
|
|
|
|
| |
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.
|
|
|
|
| |
attribute in error message, where a proc is passed.
|
|
|
|
|
|
|
|
|
| |
- 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
|
|/ |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Covers Regressions:
* <=
* <
* ==
* >
* >=
* other than
|
|\
| |
| | |
Deprecate passing string to define callback.
|
| | |
|
|/ |
|
| |
|
| |
|
|
|
|
| |
Add AC::Parameters tests for WhereChain#not
|
|
|
|
|
|
|
| |
Ok, this explains why the branch showed as green. We don't run files in
isolation for PRs, only for master. Active Support monkeypatches
`BigDecimal#to_s`, so the generated error message was different
depending on if the file was run in isolation
|
|
|
|
|
|
|
|
|
| |
The error message when asserting `greater_than: BigDecimal.new` will
give an error message based on how BigDecimal displays itself. Big
decimal appears to always use scientific notation. This might not be the
best error message for the general case, but the general case wouldn't
use big decimal for the validation. And if they do, they likely need
this level of precision.
|
|\
| |
| | |
Use the post-type-cast version of the attribute to validate numericality
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This fixes the issue where you may be comparing (using a numeric
validator such as `greater_than`) numbers of a specific Numeric type
such as `BigDecimal`.
Previous behavior took the numeric value to be validated and
unconditionally converted to Float. For example, due to floating point
precision, this can cause issues when comparing a Float to a BigDecimal.
Consider the following:
```
validates :sub_total, numericality: {
greater_than: BigDecimal('97.18')
}
```
If the `:sub_total` value BigDecimal.new('97.18') was validated against
the above, the following would be valid since `:sub_total` is converted
to a Float regardless of its original type. The result therefore becomes
Kernel.Float(97.18) > BigDecimal.new('97.18')
The above illustrated behavior is corrected with this patch by
conditionally converting the value to validate to float.
Use the post-type-cast version of the attribute to validate numericality
[Roque Pinel & Trevor Wistaff]
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This type adds an escape hatch to apps for which string duping causes
unacceptable memory growth. The reason we are duping them is in order to
detect mutation, which was a feature added to 4.2 in #15674. The string
type was modified to support this behavior in #15788.
Memory growth is really only a concern for string types, as it's the
only mutable type where the act of coersion does not create a new object
regardless (as we're usually returning an object of a different class).
I do feel strongly that if we are going to support detecting mutation,
we should do it universally for any type which is mutable. While it is
less common and ideomatic to mutate strings than arrays or hashes, there
shouldn't be rules or gotchas to understanding our behavior.
However, I also appreciate that for apps which are using a lot of string
columns, this would increase the number of allocations by a large
factor. To ensure that we keep our contract, if you'd like to opt out of
mutation detection on strings, you'll also be option out of mutation of
those strings.
I'm not completely married to the thought that strings coming out of
this actually need to be frozen -- and I think the name is correct
either way, as the purpose of this is to provide a string type which
does not detect mutation.
In the new implementation, I'm only overriding `cast_value`. I did not
port over the duping in `serialize`. I cannot think of a reason we'd
need to dup the string there, and the tests pass without it.
Unfortunately that line was introduced at a time where I was not nearly
as good about writing my commit messages, so I have no context as to
why I added it. Thanks past Sean. You are a jerk.
|
| | |
|
| |
| |
| |
| | |
Hopefully this is the last one
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Any tests for a type which is not overridden by Active Record, and does
not test the specifics of the attributes API interacting in more complex
ways have no reason to be in the Active Record suite. Doing this
revealed that the implementation of the date and time types in AM was
actually completely broken, and incapable of returning any value other
than `nil`.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Things like decorations, overrides, and priorities only matter for
Active Record, so the Active Model registry can be implemented much more
simply. At this point, I wonder if having Active Record's registry
inherit from Active Model's is even worth the trouble?
The Active Model class was also missing test cases, which have been
backfilled.
This removes the error when two types are registered with the same name,
but given that Active Model is meant to be significantly more generic, I
do not think this is an issue for now. If we want, we can raise an error
at the point that someone tries to register it.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Example:
```ruby
class Person
include ActiveModel::Validations
attr_reader :name, :title
validates_presence_of :name, on: :create
validates_presence_of :title, on: :update
end
person = Person.new
person.valid?([:create, :update]) # => true
person.errors.messages # => {:name=>["can't be blank"], :title=>["can't be blank"]}
```
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
dmitry/feature/validate-multiple-contexts-at-once"
This reverts commit 51dd2588433457960cca592d5b5dac6e0537feac, reversing
changes made to ecb4e4b21b3222b823fa24d4a0598b1f2f63ecfb.
This broke Active Record tests
|
|\ \
| | |
| | |
| | | |
Validate multiple contexts on `valid?` and `invalid?` at once
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Example:
```ruby
class Person
include ActiveModel::Validations
attr_reader :name, :title
validates_presence_of :name, on: :create
validates_presence_of :title, on: :update
end
person = Person.new
person.valid?([:create, :update]) # => true
person.errors.messages # => {:name=>["can't be blank"], :title=>["can't be blank"]}
```
|
| | |
|
| | |
|
| |
| |
| |
| | |
method_call_assertions
|
| |
| |
| |
| |
| |
| |
| | |
This includes the following classes:
- ActiveModel::Serializers::Xml
- ActiveRecord::Serialization::XmlSerializer
|
|/ |
|
|
|
|
|
|
| |
These comments do not add a lot to the readability, grepability or
overall understanding of the tests, therefore I believe they can be
safely removed.
|
|
|
|
|
| |
Activemodel is no longer dependent on mocha, so we can make the comments
more generic.
|