Long term fix & redesign of executeSelect

[prash-mi]

Long term fix & redesign of executeSelect

[shollyman]

These seem reasonable. The async design provides for some interesting permutations:

• return a future that returns the tableresult on completion, and optionally make it easy to wire job cancellation in.
• refactor TableResult so that it becomes the future

The thing to keep in mind when designing is what you want for queries that return no results, and for queries (scripts) that may return multiple result sets.

RE: 5 - The original design was for there to be three components: executeSelect, executeUpdate, and execute. My expectation is that JDBC would map to the third method, as it represents the query method where the content is ambiguous.

[prash-mi]

These seem reasonable. The async design provides for some interesting permutations:

• return a future that returns the tableresult on completion, and optionally make it easy to wire job cancellation in.
• refactor TableResult so that it becomes the future

The thing to keep in mind when designing is what you want for queries that return no results, and for queries (scripts) that may return multiple result sets.

RE: 5 - The original design was for there to be three components: executeSelect, executeUpdate, and execute. My expectation is that JDBC would map to the third method, as it represents the query method where the content is ambiguous.

Thanks for taking a look @shollyman . I will put together the async design while trying to accommodate the mentioned permutations and get back.
Regarding point#5 my initial thought was to have one synchronous method executeQuery which will return ResultSet as our current executeSelect does. We can then modify executeSelect to return a Future. This reason for this is executeQuery is a commonly used method in JDBC. WDYT?