-
Notifications
You must be signed in to change notification settings - Fork 34
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 for Issue 23 #45
Fix for Issue 23 #45
Conversation
|
Codecov Report
@@ Coverage Diff @@
## master #45 +/- ##
==========================================
+ Coverage 73.75% 74.21% +0.46%
==========================================
Files 3 3
Lines 461 512 +51
==========================================
+ Hits 340 380 +40
- Misses 121 132 +11
Continue to review full report at Codecov.
|
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.
I'd hate to hold up this long-awaited fix from going in, but there are some issues I'd like to understand better.
Perhaps they could be addressed in a subsequent PR, since this change is an improvement on the current behaviour.
} | ||
PQclear(result) | ||
return errorMessage | ||
setState(.idle) |
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.
Since setState(.idle)
is the first thing done regardless of which path we take, it would be clearer if there was a single call, moved before the if status
.
@@ -484,6 +511,7 @@ public class PostgreSQLConnection: Connection { | |||
} | |||
|
|||
PQclear(result) | |||
setState(.idle) |
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.
Same comment as above - could move single setState(.idle)
to above the if status
currentResultFetcher?.hasMoreRows = false | ||
unlockStateLock() | ||
clearResult(nil, connection: self) | ||
lockStateLock() |
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.
I think there's a potential problem here. Another thread could get in to setupForRunningQuery()
in between the unlock and lock calls. The code has to be like this because the lock used is not recursive (and would otherwise result in deadlock). I wonder if we could be using an NSRecusiveLock
instead?
import Foundation | ||
|
||
enum ConnectionState { |
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 might be better as a nested enum inside PostgreSQLConnection
, called State
.
@@ -342,6 +356,11 @@ public class PostgreSQLConnection: Connection { | |||
return | |||
} | |||
|
|||
if let error = setUpForRunningQuery() { |
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.
Naming this error
implies it's an Error
, which it isn't.
unlockStateLock() | ||
} | ||
|
||
func setUpForRunningQuery() -> String? { |
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 is weird, a setup function which returns an optional String? Why not just make it throw
?
I will defer these requested changes to the original author - @irar2 |
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.
We'll handle the improvements in a follow on PR.
These changes also help workaround issue 24.