Skip to content
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

Merged
merged 8 commits into from
Mar 14, 2018
Merged

Fix for Issue 23 #45

merged 8 commits into from
Mar 14, 2018

Conversation

dsperling
Copy link
Contributor

These changes also help workaround issue 24.

@CLAassistant
Copy link

CLAassistant commented Mar 13, 2018

CLA assistant check
Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ dsperling
❌ irar2
You have signed the CLA already but the status is still pending? Let us recheck it.

@codecov-io
Copy link

Codecov Report

Merging #45 into master will increase coverage by 0.46%.
The diff coverage is 70.76%.

Impacted file tree graph

@@            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
Flag Coverage Δ
#SwiftKueryPostgreSQL 74.21% <70.76%> (+0.46%) ⬆️
Impacted Files Coverage Δ
Sources/SwiftKueryPostgreSQL/Utils.swift 100% <100%> (+10.52%) ⬆️
...SwiftKueryPostgreSQL/PostgreSQLResultFetcher.swift 88.23% <50%> (ø) ⬆️
...es/SwiftKueryPostgreSQL/PostgreSQLConnection.swift 63.81% <68.42%> (+1.85%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3be53cc...9559614. Read the comment docs.

Copy link
Contributor

@djones6 djones6 left a 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)
Copy link
Contributor

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)
Copy link
Contributor

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()
Copy link
Contributor

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 {
Copy link
Contributor

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() {
Copy link
Contributor

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? {
Copy link
Contributor

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?

@dsperling
Copy link
Contributor Author

I will defer these requested changes to the original author - @irar2

Copy link
Contributor

@ianpartridge ianpartridge left a 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.

@djones6 djones6 merged commit 1d905f6 into Kitura:master Mar 14, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants