-
Notifications
You must be signed in to change notification settings - Fork 314
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
fix: set local schema when syncing from remote #3956
Conversation
31c68f9
to
5d2ebc2
Compare
5d2ebc2
to
88600d0
Compare
88600d0
to
7671d85
Compare
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## master #3956 +/- ##
==========================================
+ Coverage 70.72% 70.80% +0.08%
==========================================
Files 357 357
Lines 53671 53676 +5
==========================================
+ Hits 37960 38007 +47
+ Misses 13449 13416 -33
+ Partials 2262 2253 -9
☔ View full report in Codecov by Sentry. |
@achettyiitr can you redo this on |
It's hard to tell what you changed because you renamed the methods receivers. You did that all in one commit so can you either not rename the method receiver or do it in a separate commit please? |
7671d85
to
2285592
Compare
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.
This refactoring and the addition of tests is the right step forward.
In my review, I checked for the locks we are currently using, but I am not certain about all of them.
We should invest in simplifying this code further, and understand if those many locks are indeed needed.
warehouse/schema/schema.go
Outdated
s.localSchemaMu.Lock() | ||
s.localSchema = updatedSchema | ||
s.localSchemaMu.Unlock() |
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.
What is the need for maintaining s.localSchema
?
Is it for performance reasons, to avoid database queries?
Would it make sense to use the database, and figure out caching in different layers or avoid caching all together?
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.
Yes, we can simplify the logic by separating the caching into a different layer.
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.
Database queries can cost us because in some cases even the queries to INFORMATION_SCHEMAS
tables take a long time.
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.
Added a task in the Backlog so that we can revisit this again.
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.
Thanks for the changes @achettyiitr 👍
We're targeting master
here though but yesterday I had created a release and a prerelease.
If you guys (cc @lvrach) are planning to merge this into master
please close them. We need to get some closure on this though, it's starting to become confusing.
Description
Linear Ticket
Security