Swift-Kuery
Swift-Kuery copied to clipboard
Kitura
Change Connection API to be synchronous
The execute query functions will look like this:
/// Execute a query.
///
/// - Parameter query: The query to execute.
/// - Returns: An instance of QueryResult representing the result of the query execution.
func execute(query: Query) -> QueryResult
Transaction related functions will be changed in the same way:
/// Start a transaction.
///
/// - Returns: An instance of QueryResult representing the result of the execution of start transaction command.
func startTransaction() -> QueryResult
We can also throw errors instead of returning them inside QueryResult.
ResultFetcher will be synchronous only, i.e.
/// Fetch the next row of the query result. This function is non-blocking.
///
/// - Parameter callback: A callback to call when the next row of the query result is ready.
func fetchNext(callback: ([Any?]?) ->())
will be removed.
@shmuelk mentioned you were thinking about making Kuery functions throw instead of returning QueryResult.error(). IMO, that would be better. (I just saw that you also mentioned this a possibility above)
Also, if we were to do that, I think it would be worth considering moving rows and titles from ResultSet into QueryResult as optionals and removing ResultSet entirely. Then QueryResult could be as simple as:
public class QueryResult {
private let resultFetcher: ResultFetcher?
// number of rows affected by a INSERT/UPDATE/DELETE or
// number of rows returned by a SELECT (may be -1 if we fetch the result set iteratively)
public let affectedRows: Int
public let columnNames: [String]?
public let resultSet: RowSequence?
public lazy var rows: [[String: Any?]]? = {
...
}()
}
What do you think?
OK, we can do this.
@shmuelk proposed to use numberOfAffectedRows instead of affectedRows, titles instead of columnNames (because these don't have to be table columns), and rowSequence instead of resultSet.
@irar2 Hello :), Is it possible to know when the synchronous api will be released? Many thanks!
@irar2 I was reading at the implementation of the MySQL plugin and I didn't find asynchronous call to the database, so actually I was wondering why do you decide to use completion handler instead of simple return and catch ?
This item will be addressed by PR https://github.com/IBM-Swift/Swift-Kuery/pull/152
We no longer plan on addressing this via the changes related to PR #152.
We will however look at providing a utility function to wrap the asynchronous API which will allow synchronous usage of the SwiftKuery API.