-
Notifications
You must be signed in to change notification settings - Fork 21.8k
Detect in-place modifications on Strings #15788
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
Conversation
@@ -41,6 +41,7 @@ def reload(*) | |||
def initialize_dup(other) # :nodoc: | |||
super | |||
calculate_changes_from_defaults | |||
@original_raw_attributes = original_raw_attributes.dup |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just to understand, why we are needing to dup this now?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Turns out we don't. There was a different issue causing this.
@sgrif does the object allocation grew substantially with this change? For what I saw we are allocating a new string for each string attribute every time we are going to write the model instance right? |
Correct, this will increase string allocations, however in context of the
|
Detect in-place modifications on Strings
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.
No description provided.