Change Connection API to be synchronous

[irar2]

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.

[na-gupta]

@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?

[irar2]

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.

[GiacomoLeopizzi]

@irar2 Hello :),
Is it possible to know when the synchronous api will be released?
Many thanks!

[acaland]

Hi @irar2,

Having the syncronous API will be great!
Thank you in advance

[ndPPPhz]

@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 ?

[SMartorelli]

@shmuelk Would be amazing to have a synchronous API

[kilnerm]

This item will be addressed by PR #152

[kilnerm]

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.