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.
This explanation was change by https://github.com/rails/rails/commit/7a27de2b.
This change reversed the including module (`ActiveModel::Serializers::JSON`)
and the included module (`ActiveModel::Serialization`) by mistake.
Move from `AS::Callbacks::CallbackChain.halt_and_display_warning_on_return_false`
to `AS::Callbacks.halt_and_display_warning_on_return_false` base on
[this
discussion](https://github.com/rails/rails/pull/21218#discussion_r39354580)
Fix the documentation broken by 0a120a818d413c64ff9867125f0b03788fc306f8
The implementation of `attribute_method?` on Active Record requires
establishing a database connection and querying the schema. As a general
rule, we don't want to require database connections for any class macro,
as the class should be able to be loaded without a database (e.g. for
things like compiling assets).
Instead of eagerly defining these methods, we do it lazily the first
time they are accessed via `method_missing`. This should not cause any
performance hits, as it will only hit `method_missing` once for the
entire class.
The biggest source of the performance regression in these methods
occurred because dirty tracking required eagerly materializing and type
casting the assigned values. In the previous commits, I've changed dirty
tracking to perform the comparisons lazily. However, all of this is moot
when calling `save`, since `changes_applied` will be called, which just
ends up eagerly materializing everything, anyway. With the new mutation
tracker, it's easy to just compare the previous two hashes in the same
lazy fashion.
We will not have aliasing issues with this setup, which is proven by the
fact that we're able to detect nested mutation.
Before:
User.create! 2.007k (± 7.1%) i/s - 10.098k
After:
User.create! 2.557k (± 3.5%) i/s - 12.789k
Fixes#19859
This moves a bit more of the logic required for dirty checking into the
attribute objects. I had hoped to remove the `with_value_from_database`
stuff, but unfortunately just calling `dup` on the attribute objects
isn't enough, since the values might contain deeply nested data
structures. I think this can be cleaned up further.
This makes most dirty checking become lazy, and reduces the number of
object allocations and amount of CPU time when assigning a value. This
opens the door (but doesn't quite finish) to improving the performance
of writes to a place comparable to 4.1
Timestamp column can have less precision than ruby timestamp
In result in how big a fraction of a second can be stored in the
database.
m = Model.create!
m.created_at.usec == m.reload.created_at.usec
# => false
# due to different seconds precision in Time.now and database column
If the precision is low enough, (mysql default is 0, so it is always low
enough by default) the value changes when model is reloaded from the
database. This patch fixes that issue ensuring that any timestamp
assigned as an attribute is converted to column precision under the
attribute.
In Active Record, it appears these were either autoloaded, which
actually was likely due to test ordering since the method `Float#to_d`
wouldn't trigger it. This makes it explicit, and unlikely to fail in the
future.
The `override` option is only a thing for Active Record registrations.
We should figure out how to make this properly error out without doing
anything too weird to the code.
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.
We do not need to require each file from AM individually, the type
module does that for us. Even if the classes are extremely small right
now, I'd rather keep any custom classes needed by AR in their own files,
as they can easily have more complex changes in the future.
These are used by the connection adapters to convert SQL type
information into the appropriate type object, and makes no sense outside
of the context of Active Record
The thread_safe gem is being deprecated and all its code has been merged
into the concurrent-ruby gem. The new class, Concurrent::Map, is exactly
the same as its predecessor except for fixes to two bugs discovered
during the merge.
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"]}
```
This reverts commit 51dd2588433457960cca592d5b5dac6e0537feac, reversing
changes made to ecb4e4b21b3222b823fa24d4a0598b1f2f63ecfb.
This broke Active Record tests
It was not expecting the new `case_insensitive` option to be passed to
`generate_message`, instead of fixing the test we can just not pass this
option down since it is specific to the confirmation validator and not
necessary for the error message.
Case :- 1. In case of email confirmation one needs case insensitive comparison
2. In case of password confirmation one needs case sensitive comparison
[ci skip] Update Guides for case_sensitive option in confirmation validation
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"]}
```
I wrote a utility that helps find areas where you could optimize your program using a frozen string instead of a string literal, it's called [let_it_go](https://github.com/schneems/let_it_go). After going through the output and adding `.freeze` I was able to eliminate the creation of 1,114 string objects on EVERY request to [codetriage](codetriage.com). How does this impact execution?
To look at memory:
```ruby
require 'get_process_mem'
mem = GetProcessMem.new
GC.start
GC.disable
1_114.times { " " }
before = mem.mb
after = mem.mb
GC.enable
puts "Diff: #{after - before} mb"
```
Creating 1,114 string objects results in `Diff: 0.03125 mb` of RAM allocated on every request. Or 1mb every 32 requests.
To look at raw speed:
```ruby
require 'benchmark/ips'
number_of_objects_reduced = 1_114
Benchmark.ips do |x|
x.report("freeze") { number_of_objects_reduced.times { " ".freeze } }
x.report("no-freeze") { number_of_objects_reduced.times { " " } }
end
```
We get the results
```
Calculating -------------------------------------
freeze 1.428k i/100ms
no-freeze 609.000 i/100ms
-------------------------------------------------
freeze 14.363k (± 8.5%) i/s - 71.400k
no-freeze 6.084k (± 8.1%) i/s - 30.450k
```
Now we can do some maths:
```ruby
ips = 6_226k # iterations / 1 second
call_time_before = 1.0 / ips # seconds per iteration
ips = 15_254 # iterations / 1 second
call_time_after = 1.0 / ips # seconds per iteration
diff = call_time_before - call_time_after
number_of_objects_reduced * diff * 100
# => 0.4530373333993266 miliseconds saved per request
```
So we're shaving off 1 second of execution time for every 220 requests.
Is this going to be an insane speed boost to any Rails app: nope. Should we merge it: yep.
p.s. If you know of a method call that doesn't modify a string input such as [String#gsub](b0e2da69f0/lib/let_it_go/core_ext/string.rb (L37)) please [give me a pull request to the appropriate file](b0e2da69f0/lib/let_it_go/core_ext/string.rb (L37)), or open an issue in LetItGo so we can track and freeze more strings.
Keep those strings Frozen
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]
[ci skip]
Closes#20792.
Custom validation methods are implemented in terms of
callbacks. The `validate` callback chain can't be halted using return
values of individual callbacks.
[ci skip]
While this :nodoc: did hide the constant it also removed the following
methods from the API docs:
- #attribute_method?
- #clear_validators!
- #validate
- #validators
- #validators_on
Those are public API and should be visible.
Issue was caused by dee4fbc
/cc @zzak
Only one constraint option can be used at a time (except for the minimum
and maximum ones that can eventually be combined). However, other
options can be used with them (e.g. the validation failure message).
So let's make the distinction between these two different options
categories.
[Yves Senn, Matthew Draper & Robin Dupret]
This adds a script `bin/test` to most Rails framework components. The
script uses the rails minitest plugin to augment the runner.
See https://github.com/rails/rails/pull/19571 for details about the
plugin.
I did not yet add `bin/test` for activerecord, activejob and railties.
These components rely on specific setup performed in the rake-tasks.
I think we are better off leaving `sudo` outside of the documented
way of installing gems (`activerecord`, `actionpack`, …).
We don’t want newbies to think that `sudo` is required or, even worse, than
they actually have to type `[sudo] gem install`.
In most scenarios, `sudo` is not needed to install gems, and people who do
need it, probably already know about it.
What do you think? 😁
The test was skipped because of an issue that, in the meantime,
has been fixed: https://github.com/rubinius/rubinius/issues/3328.
Using the latest Rubinius (the one currently on Travis CI), this
is the result:
```sh
$ ruby --version
rubinius 2.5.3 (2.1.0 2482b093 2015-05-10 3.5.1 JI) [x86_64-darwin14.3.0]
```
**Before this PR**
```sh
$ ruby -Itest test/cases/attribute_assignment_test.rb
Run options: --seed 58569
.....S...
Finished in 0.048278s, 186.4203 runs/s, 269.2738 assertions/s.
9 runs, 13 assertions, 0 failures, 0 errors, 1 skips
You have skipped tests. Run with --verbose for details.
```
**After this PR**
$ ruby -Itest test/cases/attribute_assignment_test.rb
Run options: --seed 35720
.........
Finished in 0.029441s, 305.6961 runs/s, 475.5273 assertions/s.
9 runs, 14 assertions, 0 failures, 0 errors, 0 skips
```
`ActiveModel::Dirty#[attr_name]_previous_change` to improve access
to recorded changes after the model has been saved.
It makes the dirty-attributes query methods consistent before and after
saving.
As demonstrated by #19570, this option is severely limited, and
satisfies an extremely specific use case. Realistically, there's not
much reason for this option to exist. Its functionality can be trivially
replicated with a normal Ruby method. Let's deprecate this option, in
favor of the simpler solution.
Rails 5.0 changes to ActiveModel::Errors include addition of `details`
that also accidentally changed the return value of `delete`. Since
there was no test for that behavior it went unnoticed. This commit
adds a test and fixes the regression.
Small improvements to comments have also been made. Since `get` is
getting deprecated it is better to use `[]` in other methods' code
examples. Also, in the module usage example, `def Person.method`
was replaced with a more commonly used `def self.method` code style.
Deprecation messages in ActiveModel::Errors are using String#squish
from ActiveSupport but were not explicitly requiring it, causing failures
when used outside rails.
