1
0
Fork 0
mirror of https://github.com/rails/rails.git synced 2022-11-09 12:12:34 -05:00
rails--rails/activemodel/lib/active_model/attribute.rb

249 lines
5.9 KiB
Ruby
Raw Normal View History

# frozen_string_literal: true
require "active_support/core_ext/object/duplicable"
module ActiveModel
class Attribute # :nodoc:
class << self
PERF: 35% faster attributes for readonly usage Instantiating attributes hash from raw database values is one of the slower part of attributes. Why that is necessary is to detect mutations. In other words, that isn't necessary until mutations are happened. `LazyAttributeHash` which was introduced at 0f29c21 is to instantiate attribute lazily until first accessing the attribute (i.e. `Model.find(1)` isn't slow yet, but `Model.find(1).attr_name` is still slow). This introduces `LazyAttributeSet` to instantiate attribute more lazily, it doesn't instantiate attribute until first assigning/dirty checking the attribute (i.e. `Model.find(1).attr_name` is no longer slow). It makes attributes access about 35% faster for readonly (non-mutation) usage. https://gist.github.com/kamipo/4002c96a02859d8fe6503e26d7be4ad8 Before: ``` IPS Warming up -------------------------------------- attribute access 1.000 i/100ms Calculating ------------------------------------- attribute access 3.444 (± 0.0%) i/s - 18.000 in 5.259030s MEMORY Calculating ------------------------------------- attribute access 38.902M memsize ( 0.000 retained) 350.044k objects ( 0.000 retained) 15.000 strings ( 0.000 retained) ``` After (with `immutable_strings_by_default = true`): ``` IPS Warming up -------------------------------------- attribute access 1.000 i/100ms Calculating ------------------------------------- attribute access 4.652 (±21.5%) i/s - 23.000 in 5.034853s MEMORY Calculating ------------------------------------- attribute access 27.782M memsize ( 0.000 retained) 170.044k objects ( 0.000 retained) 15.000 strings ( 0.000 retained) ```
2020-06-13 01:36:22 -04:00
def from_database(name, value_before_type_cast, type, value = nil)
FromDatabase.new(name, value_before_type_cast, type, nil, value)
end
PERF: 35% faster attributes for readonly usage Instantiating attributes hash from raw database values is one of the slower part of attributes. Why that is necessary is to detect mutations. In other words, that isn't necessary until mutations are happened. `LazyAttributeHash` which was introduced at 0f29c21 is to instantiate attribute lazily until first accessing the attribute (i.e. `Model.find(1)` isn't slow yet, but `Model.find(1).attr_name` is still slow). This introduces `LazyAttributeSet` to instantiate attribute more lazily, it doesn't instantiate attribute until first assigning/dirty checking the attribute (i.e. `Model.find(1).attr_name` is no longer slow). It makes attributes access about 35% faster for readonly (non-mutation) usage. https://gist.github.com/kamipo/4002c96a02859d8fe6503e26d7be4ad8 Before: ``` IPS Warming up -------------------------------------- attribute access 1.000 i/100ms Calculating ------------------------------------- attribute access 3.444 (± 0.0%) i/s - 18.000 in 5.259030s MEMORY Calculating ------------------------------------- attribute access 38.902M memsize ( 0.000 retained) 350.044k objects ( 0.000 retained) 15.000 strings ( 0.000 retained) ``` After (with `immutable_strings_by_default = true`): ``` IPS Warming up -------------------------------------- attribute access 1.000 i/100ms Calculating ------------------------------------- attribute access 4.652 (±21.5%) i/s - 23.000 in 5.034853s MEMORY Calculating ------------------------------------- attribute access 27.782M memsize ( 0.000 retained) 170.044k objects ( 0.000 retained) 15.000 strings ( 0.000 retained) ```
2020-06-13 01:36:22 -04:00
def from_user(name, value_before_type_cast, type, original_attribute = nil)
FromUser.new(name, value_before_type_cast, type, original_attribute)
end
PERF: 35% faster attributes for readonly usage Instantiating attributes hash from raw database values is one of the slower part of attributes. Why that is necessary is to detect mutations. In other words, that isn't necessary until mutations are happened. `LazyAttributeHash` which was introduced at 0f29c21 is to instantiate attribute lazily until first accessing the attribute (i.e. `Model.find(1)` isn't slow yet, but `Model.find(1).attr_name` is still slow). This introduces `LazyAttributeSet` to instantiate attribute more lazily, it doesn't instantiate attribute until first assigning/dirty checking the attribute (i.e. `Model.find(1).attr_name` is no longer slow). It makes attributes access about 35% faster for readonly (non-mutation) usage. https://gist.github.com/kamipo/4002c96a02859d8fe6503e26d7be4ad8 Before: ``` IPS Warming up -------------------------------------- attribute access 1.000 i/100ms Calculating ------------------------------------- attribute access 3.444 (± 0.0%) i/s - 18.000 in 5.259030s MEMORY Calculating ------------------------------------- attribute access 38.902M memsize ( 0.000 retained) 350.044k objects ( 0.000 retained) 15.000 strings ( 0.000 retained) ``` After (with `immutable_strings_by_default = true`): ``` IPS Warming up -------------------------------------- attribute access 1.000 i/100ms Calculating ------------------------------------- attribute access 4.652 (±21.5%) i/s - 23.000 in 5.034853s MEMORY Calculating ------------------------------------- attribute access 27.782M memsize ( 0.000 retained) 170.044k objects ( 0.000 retained) 15.000 strings ( 0.000 retained) ```
2020-06-13 01:36:22 -04:00
def with_cast_value(name, value_before_type_cast, type)
WithCastValue.new(name, value_before_type_cast, type)
end
def null(name)
Null.new(name)
end
def uninitialized(name, type)
Uninitialized.new(name, type)
end
end
attr_reader :name, :value_before_type_cast, :type
# This method should not be called directly.
# Use #from_database or #from_user
PERF: 35% faster attributes for readonly usage Instantiating attributes hash from raw database values is one of the slower part of attributes. Why that is necessary is to detect mutations. In other words, that isn't necessary until mutations are happened. `LazyAttributeHash` which was introduced at 0f29c21 is to instantiate attribute lazily until first accessing the attribute (i.e. `Model.find(1)` isn't slow yet, but `Model.find(1).attr_name` is still slow). This introduces `LazyAttributeSet` to instantiate attribute more lazily, it doesn't instantiate attribute until first assigning/dirty checking the attribute (i.e. `Model.find(1).attr_name` is no longer slow). It makes attributes access about 35% faster for readonly (non-mutation) usage. https://gist.github.com/kamipo/4002c96a02859d8fe6503e26d7be4ad8 Before: ``` IPS Warming up -------------------------------------- attribute access 1.000 i/100ms Calculating ------------------------------------- attribute access 3.444 (± 0.0%) i/s - 18.000 in 5.259030s MEMORY Calculating ------------------------------------- attribute access 38.902M memsize ( 0.000 retained) 350.044k objects ( 0.000 retained) 15.000 strings ( 0.000 retained) ``` After (with `immutable_strings_by_default = true`): ``` IPS Warming up -------------------------------------- attribute access 1.000 i/100ms Calculating ------------------------------------- attribute access 4.652 (±21.5%) i/s - 23.000 in 5.034853s MEMORY Calculating ------------------------------------- attribute access 27.782M memsize ( 0.000 retained) 170.044k objects ( 0.000 retained) 15.000 strings ( 0.000 retained) ```
2020-06-13 01:36:22 -04:00
def initialize(name, value_before_type_cast, type, original_attribute = nil, value = nil)
@name = name
@value_before_type_cast = value_before_type_cast
@type = type
@original_attribute = original_attribute
PERF: 35% faster attributes for readonly usage Instantiating attributes hash from raw database values is one of the slower part of attributes. Why that is necessary is to detect mutations. In other words, that isn't necessary until mutations are happened. `LazyAttributeHash` which was introduced at 0f29c21 is to instantiate attribute lazily until first accessing the attribute (i.e. `Model.find(1)` isn't slow yet, but `Model.find(1).attr_name` is still slow). This introduces `LazyAttributeSet` to instantiate attribute more lazily, it doesn't instantiate attribute until first assigning/dirty checking the attribute (i.e. `Model.find(1).attr_name` is no longer slow). It makes attributes access about 35% faster for readonly (non-mutation) usage. https://gist.github.com/kamipo/4002c96a02859d8fe6503e26d7be4ad8 Before: ``` IPS Warming up -------------------------------------- attribute access 1.000 i/100ms Calculating ------------------------------------- attribute access 3.444 (± 0.0%) i/s - 18.000 in 5.259030s MEMORY Calculating ------------------------------------- attribute access 38.902M memsize ( 0.000 retained) 350.044k objects ( 0.000 retained) 15.000 strings ( 0.000 retained) ``` After (with `immutable_strings_by_default = true`): ``` IPS Warming up -------------------------------------- attribute access 1.000 i/100ms Calculating ------------------------------------- attribute access 4.652 (±21.5%) i/s - 23.000 in 5.034853s MEMORY Calculating ------------------------------------- attribute access 27.782M memsize ( 0.000 retained) 170.044k objects ( 0.000 retained) 15.000 strings ( 0.000 retained) ```
2020-06-13 01:36:22 -04:00
@value = value unless value.nil?
end
def value
# `defined?` is cheaper than `||=` when we get back falsy values
@value = type_cast(value_before_type_cast) unless defined?(@value)
@value
end
def original_value
if assigned?
original_attribute.original_value
else
type_cast(value_before_type_cast)
end
end
def value_for_database
type.serialize(value)
end
def changed?
changed_from_assignment? || changed_in_place?
end
def changed_in_place?
has_been_read? && type.changed_in_place?(original_value_for_database, value)
end
def forgetting_assignment
with_value_from_database(value_for_database)
end
def with_value_from_user(value)
type.assert_valid_value(value)
self.class.from_user(name, value, type, original_attribute || self)
end
def with_value_from_database(value)
self.class.from_database(name, value, type)
end
def with_cast_value(value)
self.class.with_cast_value(name, value, type)
end
Attribute assignment and type casting has nothing to do with columns It's finally finished!!!!!!! The reason the Attributes API was kept private in 4.2 was due to some publicly visible implementation details. It was previously implemented by overloading `columns` and `columns_hash`, to make them return column objects which were modified with the attribute information. This meant that those methods LIED! We didn't change the database schema. We changed the attribute information on the class. That is wrong! It should be the other way around, where schema loading just calls the attributes API for you. And now it does! Yes, this means that there is nothing that happens in automatic schema loading that you couldn't manually do yourself. (There's still some funky cases where we hit the connection adapter that I need to handle, before we can turn off automatic schema detection entirely.) There were a few weird test failures caused by this that had to be fixed. The main source came from the fact that the attribute methods are now defined in terms of `attribute_names`, which has a clause like `return [] unless table_exists?`. I don't *think* this is an issue, since the only place this caused failures were in a fake adapter which didn't override `table_exists?`. Additionally, there were a few cases where tests were failing because a migration was run, but the model was not reloaded. I'm not sure why these started failing from this change, I might need to clear an additional cache in `reload_schema_from_cache`. Again, since this is not normal usage, and it's expected that `reset_column_information` will be called after the table is modified, I don't think it's a problem. Still, test failures that were unrelated to the change are worrying, and I need to dig into them further. Finally, I spent a lot of time debugging issues with the mutex used in `define_attribute_methods`. I think we can just remove that method entirely, and define the attribute methods *manually* in the call to `define_attribute`, which would simplify the code *tremendously*. Ok. now to make this damn thing public, and work on moving it up to Active Model.
2015-01-30 16:03:36 -05:00
def with_type(type)
if changed_in_place?
with_value_from_user(value).with_type(type)
else
self.class.new(name, value_before_type_cast, type, original_attribute)
end
Attribute assignment and type casting has nothing to do with columns It's finally finished!!!!!!! The reason the Attributes API was kept private in 4.2 was due to some publicly visible implementation details. It was previously implemented by overloading `columns` and `columns_hash`, to make them return column objects which were modified with the attribute information. This meant that those methods LIED! We didn't change the database schema. We changed the attribute information on the class. That is wrong! It should be the other way around, where schema loading just calls the attributes API for you. And now it does! Yes, this means that there is nothing that happens in automatic schema loading that you couldn't manually do yourself. (There's still some funky cases where we hit the connection adapter that I need to handle, before we can turn off automatic schema detection entirely.) There were a few weird test failures caused by this that had to be fixed. The main source came from the fact that the attribute methods are now defined in terms of `attribute_names`, which has a clause like `return [] unless table_exists?`. I don't *think* this is an issue, since the only place this caused failures were in a fake adapter which didn't override `table_exists?`. Additionally, there were a few cases where tests were failing because a migration was run, but the model was not reloaded. I'm not sure why these started failing from this change, I might need to clear an additional cache in `reload_schema_from_cache`. Again, since this is not normal usage, and it's expected that `reset_column_information` will be called after the table is modified, I don't think it's a problem. Still, test failures that were unrelated to the change are worrying, and I need to dig into them further. Finally, I spent a lot of time debugging issues with the mutex used in `define_attribute_methods`. I think we can just remove that method entirely, and define the attribute methods *manually* in the call to `define_attribute`, which would simplify the code *tremendously*. Ok. now to make this damn thing public, and work on moving it up to Active Model.
2015-01-30 16:03:36 -05:00
end
def type_cast(*)
raise NotImplementedError
end
def initialized?
true
end
def came_from_user?
false
end
def has_been_read?
defined?(@value)
end
def ==(other)
self.class == other.class &&
name == other.name &&
value_before_type_cast == other.value_before_type_cast &&
type == other.type
end
alias eql? ==
def hash
[self.class, name, value_before_type_cast, type].hash
end
Make Active Record emit significantly smaller YAML This reduces the size of a YAML encoded Active Record object by ~80% depending on the number of columns. There were a number of wasteful things that occurred when we encoded the objects before that have resulted in numerous wins - We were emitting the result of `attributes_before_type_cast` as a hack to work around some laziness issues - The name of an attribute was emitted multiple times, since the attribute objects were in a hash keyed by the name. We now store them in an array instead, and reconstruct the hash using the name - The types were included for every attribute. This would use backrefs if multiple objects were encoded, but really we don't need to include it at all unless it differs from the type at the class level. (The only time that will occur is if the field is the result of a custom select clause) - `original_attribute:` was included over and over and over again since the ivar is almost always `nil`. We've added a custom implementation of `encode_with` on the attribute objects to ensure we don't write the key when the field is `nil`. This isn't without a cost though. Since we're no longer including the types, an object can find itself in an invalid state if the type changes on the class after serialization. This is the same as 4.1 and earlier, but I think it's worth noting. I was worried that I'd introduce some new state bugs as a result of doing this, so I've added an additional test that asserts mutation not being lost as the result of YAML round tripping. Fixes #25145
2016-05-31 14:44:38 -04:00
def init_with(coder)
@name = coder["name"]
@value_before_type_cast = coder["value_before_type_cast"]
@type = coder["type"]
@original_attribute = coder["original_attribute"]
@value = coder["value"] if coder.map.key?("value")
end
def encode_with(coder)
coder["name"] = name
coder["value_before_type_cast"] = value_before_type_cast unless value_before_type_cast.nil?
Make Active Record emit significantly smaller YAML This reduces the size of a YAML encoded Active Record object by ~80% depending on the number of columns. There were a number of wasteful things that occurred when we encoded the objects before that have resulted in numerous wins - We were emitting the result of `attributes_before_type_cast` as a hack to work around some laziness issues - The name of an attribute was emitted multiple times, since the attribute objects were in a hash keyed by the name. We now store them in an array instead, and reconstruct the hash using the name - The types were included for every attribute. This would use backrefs if multiple objects were encoded, but really we don't need to include it at all unless it differs from the type at the class level. (The only time that will occur is if the field is the result of a custom select clause) - `original_attribute:` was included over and over and over again since the ivar is almost always `nil`. We've added a custom implementation of `encode_with` on the attribute objects to ensure we don't write the key when the field is `nil`. This isn't without a cost though. Since we're no longer including the types, an object can find itself in an invalid state if the type changes on the class after serialization. This is the same as 4.1 and earlier, but I think it's worth noting. I was worried that I'd introduce some new state bugs as a result of doing this, so I've added an additional test that asserts mutation not being lost as the result of YAML round tripping. Fixes #25145
2016-05-31 14:44:38 -04:00
coder["type"] = type if type
coder["original_attribute"] = original_attribute if original_attribute
coder["value"] = value if defined?(@value)
end
def original_value_for_database
if assigned?
original_attribute.original_value_for_database
else
_original_value_for_database
end
end
private
attr_reader :original_attribute
alias :assigned? :original_attribute
def initialize_dup(other)
if defined?(@value) && @value.duplicable?
@value = @value.dup
end
end
def changed_from_assignment?
assigned? && type.changed?(original_value, value, value_before_type_cast)
end
def _original_value_for_database
type.serialize(original_value)
end
class FromDatabase < Attribute # :nodoc:
def type_cast(value)
type.deserialize(value)
end
def _original_value_for_database
value_before_type_cast
end
private :_original_value_for_database
end
class FromUser < Attribute # :nodoc:
def type_cast(value)
type.cast(value)
end
def came_from_user?
!type.value_constructed_by_mass_assignment?(value_before_type_cast)
end
end
class WithCastValue < Attribute # :nodoc:
def type_cast(value)
value
end
def changed_in_place?
false
end
end
class Null < Attribute # :nodoc:
def initialize(name)
super(name, nil, Type.default_value)
end
Attribute assignment and type casting has nothing to do with columns It's finally finished!!!!!!! The reason the Attributes API was kept private in 4.2 was due to some publicly visible implementation details. It was previously implemented by overloading `columns` and `columns_hash`, to make them return column objects which were modified with the attribute information. This meant that those methods LIED! We didn't change the database schema. We changed the attribute information on the class. That is wrong! It should be the other way around, where schema loading just calls the attributes API for you. And now it does! Yes, this means that there is nothing that happens in automatic schema loading that you couldn't manually do yourself. (There's still some funky cases where we hit the connection adapter that I need to handle, before we can turn off automatic schema detection entirely.) There were a few weird test failures caused by this that had to be fixed. The main source came from the fact that the attribute methods are now defined in terms of `attribute_names`, which has a clause like `return [] unless table_exists?`. I don't *think* this is an issue, since the only place this caused failures were in a fake adapter which didn't override `table_exists?`. Additionally, there were a few cases where tests were failing because a migration was run, but the model was not reloaded. I'm not sure why these started failing from this change, I might need to clear an additional cache in `reload_schema_from_cache`. Again, since this is not normal usage, and it's expected that `reset_column_information` will be called after the table is modified, I don't think it's a problem. Still, test failures that were unrelated to the change are worrying, and I need to dig into them further. Finally, I spent a lot of time debugging issues with the mutex used in `define_attribute_methods`. I think we can just remove that method entirely, and define the attribute methods *manually* in the call to `define_attribute`, which would simplify the code *tremendously*. Ok. now to make this damn thing public, and work on moving it up to Active Model.
2015-01-30 16:03:36 -05:00
def type_cast(*)
nil
end
def with_type(type)
self.class.with_cast_value(name, nil, type)
end
def with_value_from_database(value)
raise ActiveModel::MissingAttributeError, "can't write unknown attribute `#{name}`"
end
alias_method :with_value_from_user, :with_value_from_database
alias_method :with_cast_value, :with_value_from_database
end
class Uninitialized < Attribute # :nodoc:
UNINITIALIZED_ORIGINAL_VALUE = Object.new
def initialize(name, type)
super(name, nil, type)
end
def value
if block_given?
yield name
end
end
def original_value
UNINITIALIZED_ORIGINAL_VALUE
end
def value_for_database
end
def initialized?
false
end
Make Active Record emit significantly smaller YAML This reduces the size of a YAML encoded Active Record object by ~80% depending on the number of columns. There were a number of wasteful things that occurred when we encoded the objects before that have resulted in numerous wins - We were emitting the result of `attributes_before_type_cast` as a hack to work around some laziness issues - The name of an attribute was emitted multiple times, since the attribute objects were in a hash keyed by the name. We now store them in an array instead, and reconstruct the hash using the name - The types were included for every attribute. This would use backrefs if multiple objects were encoded, but really we don't need to include it at all unless it differs from the type at the class level. (The only time that will occur is if the field is the result of a custom select clause) - `original_attribute:` was included over and over and over again since the ivar is almost always `nil`. We've added a custom implementation of `encode_with` on the attribute objects to ensure we don't write the key when the field is `nil`. This isn't without a cost though. Since we're no longer including the types, an object can find itself in an invalid state if the type changes on the class after serialization. This is the same as 4.1 and earlier, but I think it's worth noting. I was worried that I'd introduce some new state bugs as a result of doing this, so I've added an additional test that asserts mutation not being lost as the result of YAML round tripping. Fixes #25145
2016-05-31 14:44:38 -04:00
def forgetting_assignment
dup
end
def with_type(type)
self.class.new(name, type)
end
Make Active Record emit significantly smaller YAML This reduces the size of a YAML encoded Active Record object by ~80% depending on the number of columns. There were a number of wasteful things that occurred when we encoded the objects before that have resulted in numerous wins - We were emitting the result of `attributes_before_type_cast` as a hack to work around some laziness issues - The name of an attribute was emitted multiple times, since the attribute objects were in a hash keyed by the name. We now store them in an array instead, and reconstruct the hash using the name - The types were included for every attribute. This would use backrefs if multiple objects were encoded, but really we don't need to include it at all unless it differs from the type at the class level. (The only time that will occur is if the field is the result of a custom select clause) - `original_attribute:` was included over and over and over again since the ivar is almost always `nil`. We've added a custom implementation of `encode_with` on the attribute objects to ensure we don't write the key when the field is `nil`. This isn't without a cost though. Since we're no longer including the types, an object can find itself in an invalid state if the type changes on the class after serialization. This is the same as 4.1 and earlier, but I think it's worth noting. I was worried that I'd introduce some new state bugs as a result of doing this, so I've added an additional test that asserts mutation not being lost as the result of YAML round tripping. Fixes #25145
2016-05-31 14:44:38 -04:00
end
private_constant :FromDatabase, :FromUser, :Null, :Uninitialized, :WithCastValue
end
end