-
-
Notifications
You must be signed in to change notification settings - Fork 1.6k
Connection pool #411
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
Connection pool #411
Conversation
Uses WAL mode to support multiple reads and a single writer.
Allows customizing new connections once created
ConnectionType is now Connection and Connection is now DBConnection
vfs seems to be a more reliable handling of exclusive mode.
|
||
|
||
/// Protocol to an SQLite connection | ||
public protocol Connection { |
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.
Per the Swift naming guidelines can we make this ConnectionProtocol
and retain the default Connection
class name?
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.
Wouldn't ConnectionType
be more Switfy? (thinking of SequenceType
, etc)
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 haven't kept up on the Swift-Evo list as of late. I know they are renaming basically everything.
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.
Also, I kind of liked having DBConnection
, regardless of the protocol name, simply because it has more capabilities than the protocol does and the name kind of explains why in that case. Although, with a renamed protocol, simply Connection
works as well.
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.
Yep, this is the proposal: https://github.com/apple/swift-evolution/blob/master/proposals/0006-apply-api-guidelines-to-the-standard-library.md
Strip
Type
suffix from protocol names. In a few special cases this means adding aProtocol
suffix to get out of the way of type names that are primary (though most of these we expect to be obsoleted by Swift 3 language features).
I need to go back and update the other Type
-suffixed protocols, as well.
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.
Given this I'd love to keep it as is. Connection
, DBConnection
& BorrowedConnection
(although you never use it directly) are more descriptive and seem to be more in line with the eventual Swift naming schemes; the alternative of ConnectionProtocol
, Connection
& BorrowedConnection
seems less desirable to me even if it means a bit of renaming in projects.
In reality, projects shouldn't have to do much renaming at all since Connection
just becomes a protocol. Only during initialization & when using special functions would you need to use DBConnection
.
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 wonder if we can find another, happier medium. The reaction I had to the current naming direction is that it's a little harder to derive specific meaning on its own. I'm left wondering why only one of the types is prefixed with the abbreviation DB
and what the significance of DB
has over the other types. I also wonder if decorators like DB
are slightly redundant in a SQLite library.
I actually prefer ConnectionType
over ConnectionProtocol
, but was trying to move in the general direction of Swift norms. I wonder if we could come up with a different protocol name that we like even better. Or maybe DBConnection
could change to something else, like ConcreteConnection
, though that descriptor still seems slightly confusing to me.
Any other ideas?
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 agree that 'DB' wasn't the best. Prior to that I had almost settled on DirectConnection
. Which may be more to your liking?
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.
Yup! Definitely prefer that! Has very clear meaning on its own.
This is great! Naming/delegate question aside, I'd love to get this merged! |
@stephencelis Updated to use setup closures very close to your suggestion. Like it much better. Also renamed to |
Was using incorrect dispatch_once token.
# Conflicts: # SQLiteTests/ConnectionPoolTests.swift
Looking good! Going to check it out and put it through some tests before merging. |
|
||
var borrowed : BorrowedConnection! | ||
|
||
repeat { |
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.
Isn't this a busy loop? If all the readers are checked out it would appear this method will just keep repeating busily until one is available. Would be a lot better to use a dispatch_semaphore
or NSCondition
to let it sleep and get a signal when a connection is actually available.
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.
To be honest I need to look at this again... This seems to be a holdover from an earlier version/feature. This code should find an available connection, wait for one or fail. None of that requires a loop. Good catch!
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.
Right now because it will always create a new reader it'll never busy loop, but if it didn't it would create a busy loop just need a signal of some sort…
You also want to make sure that signal isn't does block the lockQueue
otherwise a connection wont be able to be checked 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.
I did this in 960309e and would appreciate any feedback.
@kdubb: Is there something I can do to help get this through? I don't want to step on any toes but I'd love to see this in and am willing to finish up whatever's remaining if you're too busy at the moment. |
@@ -67,10 +268,32 @@ public final class Connection { | |||
/// Default: `false`. | |||
/// | |||
/// - Returns: A new database connection. | |||
public init(_ location: Location = .InMemory, readonly: Bool = false) throws { | |||
public convenience init(_ location: Location = .InMemory, readonly: Bool = false, vfsName: String? = nil) throws { |
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.
Looks like the function docs above need to be updated to include the vfsName
parameter.
I opened #451 because this doesn't seem to be going anywhere. Let me know if there's a better way to get this through than opening a new PR. |
@nickmshelley My apologies I hadn't seen the resurrection of this PR until I was just notified about it being merged. All worked out it seems! |
@kdubb I hope so. Sorry if I stole any thunder. |
Also thanks for doing the bulk of the work @kdubb. |
Thanks for shepherding this, @nickmshelley! |
Implement simultaneous multi reader, single write connection pool. Uses WAL and exclusive VFS mode to achieve concurrency.