| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
| |
with new transaction state. If AR object has a callback, the callback will be performed immediately (non-lazily) so the transaction still has to keep records with callbacks.
|
|
|
|
| |
see: https://github.com/blog/1406-namespaced-gists
|
|
|
|
|
|
| |
With the addition of String#in_time_zone and Date#in_time_zone
we can simplify the type casting code by checking if the value
has an `in_time_zone` method.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, when `time_zone_aware_attributes` were enabled, after
changing a datetime or timestamp attribute and then changing it back
to the original value, `changed_attributes` still tracked the
attribute as changed. This caused `[attribute]_changed?` and
`changed?` methods to return true incorrectly.
Example:
in_time_zone 'Paris' do
order = Order.new
original_time = Time.local(2012, 10, 10)
order.shipped_at = original_time
order.save
order.changed? # => false
# changing value
order.shipped_at = Time.local(2013, 1, 1)
order.changed? # => true
# reverting to original value
order.shipped_at = original_time
order.changed? # => false, used to return true
end
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit e9d2ad395ec2ef929d74752f3d71c80674044fbe.
Closes #8460
Conflicts:
activerecord/lib/active_record/attribute_methods/time_zone_conversion.rb
activerecord/test/cases/dirty_test.rb
|
| |
|
|
|
|
|
|
| |
* dependencies/autoload
* concern
* deprecation
|
| |
|
|
|
|
| |
Fix #8575
|
|
|
|
|
|
|
| |
Setting a nil datetime attribute to a blank string should not cause the
attribute to be dirty.
Fix #8310
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This improves memory and performance without having to use symbols which
present DoS problems. Thanks @headius and @tenderlove for the
suggestion.
This was originally committed in
f1765019ce9b6292f2264b4601dad5daaffe3a89, and then reverted in
d3494903719682abc0948bef290af0d3d7b5a440 due to it causing problems in a
real application. This second attempt should solve that.
Benchmark
---------
require 'active_record'
require 'benchmark/ips'
ActiveRecord::Base.establish_connection(adapter: 'sqlite3', database: ':memory:')
class Post < ActiveRecord::Base
connection.create_table :posts, force: true do |t|
t.string :name
end
end
post = Post.create name: 'omg'
Benchmark.ips do |r|
r.report('Post.new') { Post.new name: 'omg' }
r.report('post.name') { post.name }
r.report('post.name=') { post.name = 'omg' }
r.report('Post.find(1).name') { Post.find(1).name }
end
Before
------
Calculating -------------------------------------
Post.new 1419 i/100ms
post.name 7538 i/100ms
post.name= 3024 i/100ms
Post.find(1).name 243 i/100ms
-------------------------------------------------
Post.new 20637.6 (±12.7%) i/s - 102168 in 5.039578s
post.name 1167897.7 (±18.2%) i/s - 5186144 in 4.983077s
post.name= 64305.6 (±9.6%) i/s - 317520 in 4.998720s
Post.find(1).name 2678.8 (±10.8%) i/s - 13365 in 5.051265s
After
-----
Calculating -------------------------------------
Post.new 1431 i/100ms
post.name 7790 i/100ms
post.name= 3181 i/100ms
Post.find(1).name 245 i/100ms
-------------------------------------------------
Post.new 21308.8 (±12.2%) i/s - 105894 in 5.053879s
post.name 1534103.8 (±2.1%) i/s - 7634200 in 4.979405s
post.name= 67441.0 (±7.5%) i/s - 337186 in 5.037871s
Post.find(1).name 2681.9 (±10.6%) i/s - 13475 in 5.084511s
|
| |
|
|
|
|
| |
We should not need any `serialized_attributes` checks outside `ActiveRecord::AttributeMethods::Serialization` module.
|
|\
| |
| |
| |
| |
| |
| | |
Conflicts:
actionpack/lib/action_controller/metal/mime_responds.rb
activerecord/lib/active_record/attribute_methods.rb
guides/source/working_with_javascript_in_rails.md
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
This reverts commit f1765019ce9b6292f2264b4601dad5daaffe3a89.
|
| |
| |
| |
| | |
Public method `attributes_before_type_cast` used to return internal AR structure (ActiveRecord::AttributeMethods::Serialization::Attribute), patch fixes this. Now behaves like `read_attribute_before_type_cast` and returns unserialised values.
|
| | |
|
| |
| |
| |
| | |
It's sometimes hard to quickly find where deprecated call was performed, especially in case of migrating between Rails versions. So this is an attempt to improve the call stack part of the warning message by providing caller explicitly.
|
|/
|
|
|
|
|
|
|
|
| |
In the end I think the pain of implementing this seamlessly was not
worth the gain provided.
The intention was that it would allow plain ruby objects that might not
live in your main application to be subclassed and have persistence
mixed in. But I've decided that the benefit of doing that is not worth
the amount of complexity that the implementation introduced.
|
|
|
|
| |
This reverts commit 83846838252397b3781eed165ca301e05db39293.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
I think it's going to be too much pain to try to transition the
:active_record load hook from executing against Base to executing
against Model.
For example, after Model is included in Base, and modules included in
Model will no longer get added to the ancestors of Base.
So plugins which wish to be compatible with both Model and Base should
use the :active_record_model load hook which executes *before* Base gets
loaded.
In general, ActiveRecord::Model is an advanced feature at the moment and
probably most people will continue to inherit from ActiveRecord::Base
for the time being.
|
|
|
|
| |
This reflects the fact that it now impact inserts as well as updates.
|
|
|
|
|
|
|
|
|
| |
In non-strict mode it is '', but if someone is in strict mode then we
should honour the strict semantics.
Also, this removes the need for a completely horrible hack in dirty.rb.
Closes #7780
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This improves memory and performance without having to use symbols which
present DoS problems. Thanks @headius and @tenderlove for the
suggestion.
Benchmark
---------
require 'active_record'
require 'benchmark/ips'
ActiveRecord::Base.establish_connection(adapter: 'sqlite3', database:
':memory:')
class Post < ActiveRecord::Base
connection.create_table :posts, force: true do |t|
t.string :name
end
end
post = Post.create name: 'omg'
Benchmark.ips do |r|
r.report('Post.new') { Post.new name: 'omg' }
r.report('post.name') { post.name }
r.report('post.name=') { post.name = 'omg' }
r.report('Post.find(1).name') { Post.find(1).name }
end
Before
------
Calculating -------------------------------------
Post.new 1419 i/100ms
post.name 7538 i/100ms
post.name= 3024 i/100ms
Post.find(1).name 243 i/100ms
-------------------------------------------------
Post.new 20637.6 (±12.7%) i/s - 102168 in 5.039578s
post.name 1167897.7 (±18.2%) i/s - 5186144 in 4.983077s
post.name= 64305.6 (±9.6%) i/s - 317520 in 4.998720s
Post.find(1).name 2678.8 (±10.8%) i/s - 13365 in 5.051265s
After
-----
Calculating -------------------------------------
Post.new 1431 i/100ms
post.name 7790 i/100ms
post.name= 3181 i/100ms
Post.find(1).name 245 i/100ms
-------------------------------------------------
Post.new 21308.8 (±12.2%) i/s - 105894 in 5.053879s
post.name 1534103.8 (±2.1%) i/s - 7634200 in 4.979405s
post.name= 67441.0 (±7.5%) i/s - 337186 in 5.037871s
Post.find(1).name 2681.9 (±10.6%) i/s - 13475 in 5.084511s
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 86c3dfbd47cb96af02daaa655963292b1a1b110e.
Conflicts:
activerecord/lib/active_record/attribute_methods/read.rb
Reason: whilst this increased performance, it also presents a DoS risk
via memory exhaustion if users were allowing user input to dictate the
arguments of read/write_attribute. I will investigate alternative ways
to cut down on string allocations here.
|
|\
| |
| |
| |
| | |
Conflicts:
actionpack/lib/action_view/helpers/asset_tag_helper.rb
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When inserting new records, only the fields which have been changed
from the defaults will actually be included in the INSERT statement.
The other fields will be populated by the database.
This is more efficient, and also means that it will be safe to
remove database columns without getting subsequent errors in running
app processes (so long as the code in those processes doesn't
contain any references to the removed column).
|
|/ |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When calling a query method on an attribute that was not selected by
an ActiveRecord query, an ActiveModel::MissingAttributeError is not
raised. Instead, a nil value is returned, which will return false once
cast to boolean.
This is undesirable, as we should not give the impression that we know
the attribute's boolean value when we haven't loaded the attribute's
(possibly) non-boolean value from the database.
This issue is present on versions going back as far as 2.3, at least.
|
|
|
|
|
|
| |
* There is no need to delete the primary key from cloned attributes,
since it sets the same pk to nil afterwards.
* Check for empty? instead of any? to run initialize callbacks.
|
|
|
|
|
|
| |
This is purely a performance optimisation.
See https://gist.github.com/3552829
|
|
|
|
|
|
|
|
| |
This is a performance/GC optimisation.
In theory, this could be optimised by the implementation (last time I
checked, this would have no effect on JRuby). But in practise, this make
attribute access faster.
|
| |
|
| |
|
| |
|