-
Notifications
You must be signed in to change notification settings - Fork 21.4k
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
schema_load triggers 2nd schema_load (via locking) #24653
Conversation
Thanks for the pull request, and welcome! The Rails team is excited to review your changes, and you should hear from @matthewd (or someone else) soon. If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes. Please see the contribution instructions for more information. |
@@ -150,7 +150,7 @@ def locking_column=(value) | |||
|
|||
# The version column used for optimistic locking. Defaults to +lock_version+. | |||
def locking_column | |||
reset_locking_column unless defined?(@locking_column) | |||
@locking_column = DEFAULT_LOCKING_COLUMN unless defined?(@locking_column) |
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.
Do you know why reset_locking_column
invalidated the schema?
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.
@rafaelfranca I am not sure if you asked do I know why that is wanted, or literally how is that done.
locking_column
callsreset_locking_column
reset_locking_column
callslocking_column=
locking_column=
callsreload_schema_from_cache
I'm looking into writing tests for this. but they are a little tricky
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.
@rafaelfranca looked through history of this file (didn't branch out to other files) and even wondering if locking_column=
or reset_locking_column
even needs to reload the schema.
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.
Oh, that was the information I was looking, thanks.
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.
If table_name=
reload the schema so they should.
added tests. Here are the numbers from before this PR and after.
|
023d2d5
to
2b5faec
Compare
rebased to kick build. (jruby timeout looked bogus) (I didn't squash, but can if you want that) |
Currently, loading the schema (schema_load) accesses the locking column (locking_column) which defaults the value (reset_locking_column) which invalidates the schema (reload_schema_from_cache) which forces another schema load. Good news: The second schema_load does accesses locking_column, but locking_column is set, so it does not reset_locking_column and it does not trigger an infinite loop. The solution is not invalidate the cache while default locking_column
2b5faec
to
ba05b3c
Compare
kicking again. hope faye build failure is not related |
Thanks @rafaelfranca |
@@ -0,0 +1,53 @@ | |||
require 'thread' |
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.
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.
Thank you @jeremy - very good eye. I found a solution that no longer needed the thread but it got left in.
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.
Thank you but all kudos to @vipulnsward's sharp eye 😊
Summary
Rails is double loading (
schema_load!
) for all of our models.Details
Currently, loading the schema (
schema_load
)accesses the locking column (
locking_column
)which defaults the value (
reset_locking_column
)which invalidates the schema (
reload_schema_from_cache
)which forces another schema load (
schema_load
).Good news:
The second
schema_load
does accesseslocking_column
,but
locking_column
is set this time through, so it does not callreset_locking_column
and it does not trigger an infinite loop.
Solution
I feel
reset_locking_column
should still invalidate the schema.So instead, this sets
@locking_column
directly in the default case only.Please let me know if you have another solution.
/cc @matthewd