-
Notifications
You must be signed in to change notification settings - Fork 313
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
raw type should be able to deserialize #2268
base: master
Are you sure you want to change the base?
Conversation
Related to rails/rails#44317 |
Basically if we always use And if we believe that |
`#forgetting_assignment` was introduced with 07723c2, and it involved deserializing and then serializing current value. This is an unnecessary extra operation, and also it is a problem for custom attribute types where `#serialize` and `#deserialize` are not inverse to each other operations. This is a problem for example when using oracle-enhanced-adapter. fixes rails#44317 and rails#42738 and rsim/oracle-enhanced#2268
ActiveRecord expects types to properly deserialize any values that have been serialized. Right now (Rails 7.1) by every object save the attributes are reset by serialize/deserialize cycle. see ActiveModel::ActiveModel#forget_attribute_assignments
@yahonda , I updated implementation and description of this PR. But now all tests fail for some issue with |
bump |
ActiveRecord expects types to properly deserialize any values that
have been serialized. Right now (Rails 7.1) by every object save the
attributes are reset by serialize/deserialize cycle.
see ActiveModel::ActiveModel#forget_attribute_assignments
It might be inefficient but other parts of ActiveRecord and ActiveModel attributes also rely on serialize and deserialize being reversible. At least I saw that
#changed_in_place?
expects this to be true in some types like Serialized. So it is rather complicated to change Rails to prevent that.And also it makes intuitive sense that if our class has
#serialize
and#deserialize
methods, that they reverse each other.So to avoid confusing errors now and going forward, I believe we need this change.
This is more of a hack but I'm not sure of a better way to fix. Provided that we can use#write_lobs
for such inserts, then I don't know why we should serialize and insert with the insert statement thus need the#serialize
? Related to #2226I feel there should be a better fix but I'm confused with the whole idea around lob writing.