2017-07-09 13:41:28 -04:00
|
|
|
# frozen_string_literal: true
|
|
|
|
|
2017-10-19 12:45:07 -04:00
|
|
|
require "active_model/attribute"
|
2015-05-28 18:26:49 -04:00
|
|
|
|
2017-10-19 12:45:07 -04:00
|
|
|
module ActiveModel
|
2015-05-28 18:26:49 -04:00
|
|
|
class Attribute # :nodoc:
|
2015-08-12 07:24:21 -04:00
|
|
|
class UserProvidedDefault < FromUser # :nodoc:
|
Persist user provided default values, even if unchanged
This is a usability change to fix a quirk from our definition of partial
writes. By default, we only persist changed attributes. When creating a
new record, this is assumed that the default values came from the
database. However, if the user provided a default, it will not be
persisted, since we didn't see it as "changed". Since this is a very
specific case, I wanted to isolate it with the other quirks that come
from user provided default values. The number of edge cases which are
presenting themselves are starting to make me wonder if we should just
remove the ability to assign a default, in favor of overriding
`initialize`. For the time being, this is required for the attributes
API to not have confusing behavior.
We had to delete one test, since this actually changes the meaning of
`.changed?` on Active Record models. It now specifically means
`changed_from_database?`. While I think this will make the attributes
API more ergonomic to use, it is a subtle change in definition (though
not a backwards incompatible one). We should probably figure out the
right place to document this. (Feel free to open a PR doing that if
you're reading this).
/cc @rafaelfranca @kirs @senny
This is an alternate implementation of #19921.
Close #19921.
[Sean Griffin & Kir Shatrov]
2015-05-28 18:33:38 -04:00
|
|
|
def initialize(name, value, type, database_default)
|
2016-03-24 16:54:02 -04:00
|
|
|
@user_provided_value = value
|
2015-09-28 17:12:28 -04:00
|
|
|
super(name, value, type, database_default)
|
2015-05-28 18:26:49 -04:00
|
|
|
end
|
|
|
|
|
2016-03-24 16:54:02 -04:00
|
|
|
def value_before_type_cast
|
|
|
|
if user_provided_value.is_a?(Proc)
|
|
|
|
@memoized_value_before_type_cast ||= user_provided_value.call
|
2015-05-28 18:26:49 -04:00
|
|
|
else
|
2016-03-24 16:54:02 -04:00
|
|
|
@user_provided_value
|
2015-05-28 18:26:49 -04:00
|
|
|
end
|
|
|
|
end
|
Persist user provided default values, even if unchanged
This is a usability change to fix a quirk from our definition of partial
writes. By default, we only persist changed attributes. When creating a
new record, this is assumed that the default values came from the
database. However, if the user provided a default, it will not be
persisted, since we didn't see it as "changed". Since this is a very
specific case, I wanted to isolate it with the other quirks that come
from user provided default values. The number of edge cases which are
presenting themselves are starting to make me wonder if we should just
remove the ability to assign a default, in favor of overriding
`initialize`. For the time being, this is required for the attributes
API to not have confusing behavior.
We had to delete one test, since this actually changes the meaning of
`.changed?` on Active Record models. It now specifically means
`changed_from_database?`. While I think this will make the attributes
API more ergonomic to use, it is a subtle change in definition (though
not a backwards incompatible one). We should probably figure out the
right place to document this. (Feel free to open a PR doing that if
you're reading this).
/cc @rafaelfranca @kirs @senny
This is an alternate implementation of #19921.
Close #19921.
[Sean Griffin & Kir Shatrov]
2015-05-28 18:33:38 -04:00
|
|
|
|
|
|
|
def with_type(type)
|
2016-03-24 16:54:02 -04:00
|
|
|
self.class.new(name, user_provided_value, type, original_attribute)
|
Persist user provided default values, even if unchanged
This is a usability change to fix a quirk from our definition of partial
writes. By default, we only persist changed attributes. When creating a
new record, this is assumed that the default values came from the
database. However, if the user provided a default, it will not be
persisted, since we didn't see it as "changed". Since this is a very
specific case, I wanted to isolate it with the other quirks that come
from user provided default values. The number of edge cases which are
presenting themselves are starting to make me wonder if we should just
remove the ability to assign a default, in favor of overriding
`initialize`. For the time being, this is required for the attributes
API to not have confusing behavior.
We had to delete one test, since this actually changes the meaning of
`.changed?` on Active Record models. It now specifically means
`changed_from_database?`. While I think this will make the attributes
API more ergonomic to use, it is a subtle change in definition (though
not a backwards incompatible one). We should probably figure out the
right place to document this. (Feel free to open a PR doing that if
you're reading this).
/cc @rafaelfranca @kirs @senny
This is an alternate implementation of #19921.
Close #19921.
[Sean Griffin & Kir Shatrov]
2015-05-28 18:33:38 -04:00
|
|
|
end
|
2016-03-24 16:54:02 -04:00
|
|
|
|
2018-01-23 16:08:46 -05:00
|
|
|
def marshal_dump
|
|
|
|
result = [
|
|
|
|
name,
|
|
|
|
value_before_type_cast,
|
|
|
|
type,
|
|
|
|
original_attribute,
|
|
|
|
]
|
|
|
|
result << value if defined?(@value)
|
|
|
|
result
|
|
|
|
end
|
|
|
|
|
|
|
|
def marshal_load(values)
|
|
|
|
name, user_provided_value, type, original_attribute, value = values
|
|
|
|
@name = name
|
|
|
|
@user_provided_value = user_provided_value
|
|
|
|
@type = type
|
|
|
|
@original_attribute = original_attribute
|
|
|
|
if values.length == 5
|
|
|
|
@value = value
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2018-02-25 16:14:17 -05:00
|
|
|
private
|
2016-08-06 13:55:02 -04:00
|
|
|
attr_reader :user_provided_value
|
2015-05-28 18:26:49 -04:00
|
|
|
end
|
|
|
|
end
|
|
|
|
end
|