This is a fairly large set of changes to the unit tests that help isolate the effectiveness of the unit tests.
* Unit tests for query execution have been split into separate files for different classes.
* Unit tests have been added for the ResultSet class which previously did not have tests
* The InMemoryStreamWrapper has been improved to share memory, creating a simulated filesystem
* Creating a mock ConnectionService to decrease noisy exceptions and prevent "row stealing". Unfortunately this lowers code coverage. However, since the tests that touched the connection service were not really testing it, this helps keep us honest. But it will require adding more unit tests for connection service.
* Standardizing the await mechanism for query execution
* Cleaning up the mechanism for getting WorkspaceService mocks and mock FileStreamFactories
* Refactor the query execution tests into their own files
* Removing tests from ExecuteTests.cs that were moved to separate files
* Adding tests for ResultSet class
* Adding test for the FOR XML/JSON component of the resultset class
* Setting up shared storage between file stream readers/writers
* Standardizing on Workspace mocking, awaiting execution completion
* Adding comment for ResultSet class
* Adding useful unit tests for this functionality
* Adding callback functionality for when a file is closed
* Fixing bad data issue w/closing/opening untitled doc
* Adding useful unit tests for this functionality
* Adding callback functionality for when a file is closed
* Moving from public to internal
* Adding useful unit tests for this functionality
* Adding callback functionality for when a file is closed
* Fixing bad data issue w/closing/opening untitled doc
* Adding useful unit tests for this functionality
* Adding callback functionality for when a file is closed
* Moving from public to internal
The main feature of this pull request is a new callback that's added to the query class that is called when a batch has completed execution and retrieval of results. This callback will send an event to the extension with the batch summary information. After that, the extension can submit subset requests for the resultsets of the batch.
Other smaller changes in this pull request:
Refactor to assign a batch a id when its created instead of when returning the list of batch summaries
Passing the SelectionData around instead of extracting the values for it
Moving creation of BatchSummary into the Batch class
Retrieval of results is now permitted even if the entire query has not completed, as long as the batch requested has completed.
Also note, this does not break the protocol. It adds a new event that a queryRunner can listen to, but it doesn't require it to be listened to.
* Refactor to remove SectionData class in favor of BufferRange
* Adding callback for batch completion that will let the extension know that a batch has completed execution
* Refactoring to make progressive results work as per async query execution
* Allowing retrieval of batch results while query is in progress
* reverting global.json, whoops
* Adding a few missing comments, and fixing a couple code style bugs
* Using SelectionData everywhere again
* One more missing comment
Auto-merging test-only changes. Please review the commit and I'll make changes in next iteration.
* Add more tests to boast code coverage
* Add more reliable connection tests.
Next round of code coverage test cases. Please review the commit for next iteration.
* Add connection retry tests
* More test coverage
* Update diagnostics end-to-end test
Test-only changes for code coverage. Please review the comment and I'll include the changes in the next iteration.
* Add more tests
* Add some more additional test cases
These are test-only changes to improve code coverage so I'll merge directly. Please review the commit and I'll pickup those changes in the next iteration.
* Add integration test batch file
* Exclude Linux and MacOS from Windows code coverage builds
* Enable code coverage for test driver e2e tests
* Use the windows only build for code coverage runs
* Make save results asynchronous
* Prevent write share of file
* Lock objects in stages
* Create Save result objects
* refactor and write rows in batches
* CHange batchSize from test value
* Remove await in handler
* Removing the file reader as a member of the resultset
* Change Dispose to wait for save
* Change concurrentBag
* PascalCase variables
* Modify function signature and tests
* Safe file methods
* refactor ResultSets to Ilist and remove ToList
* Change dictionary key and prevent add to saveTasks during dispose
* Simplify row concatenation
* Fix prevent add
* Fix prevent add
* Add methods to expose saveTasks and isBeingDisposed
After much thinking, this change brings the message behavior into line with SSMS, including if the NOCOUNT is set. This is a somewhat non-obvious solution, but the StatementCompleted event handler will only be fired if there is a record count to return. We'll add the message for number of records if the StatementCompleted event is fired, otherwise we won't add any messages while processing the resultsets of the batch. If any messages are returned from the server, we'll capture those. Then, if at the end of the batch, we haven't collected any messages from StatementCompleted events or server messages, then we'll add the "completed successfully" message.
This matches behavior of SSMS that will only emit a "completed successfully" message if there were no other messages for the batch.
* Solution to issue, some unit tests needed to be tweaked
* Comments for the event handler
* Ported ReliableConnectionTests from DacFx and added a few more tests
* Fix style
* Created integration tests configuration and fixed minor test issue
Moving some logic around such that when a query is cancelled, it isn't thrown away, allowing reading of the partial results, a la SSMS.
Adding a configure await to fix a tenacious bug causing query cancellations to hang for 20s or more.
Capturing sql errors for user cancellation, to return all user cancelation scenarios using the same messages. (ie, cancelling during ExecuteReaderAsync will yield a error from the server whereas cancelling during ReadAsync throws a TaskCancelledException
No changes to protocol, just implementation changes.
* Test of try/finally
* Fixed issue where resultsets are unreadable after query cancellation
* Fix for await/async issue
