David Shiflet

Results 53 comments of David Shiflet

Would it make sense for Rows to accumulate the messages instead of relying on any kind of queue or callback? I am not certain what other options have been discussed...

FWIW I can make this test pass. Obviously I need to write some more extensive tests and clean things up for any type of PR but it's a start. ```go...

I'm finding several benefits to this "nonblocking" implementation that should be applicable to the non-message-loop based model. 1. Today, `rows.NextResultSet()` does not successfully advance to the next record set in...

varbinary handling overall looks funny. EDIT: this behavior difference seems to be a convention for varbinary conversion to string as described here: https://docs.microsoft.com/sql/odbc/reference/appendixes/sql-to-c-binary?view=sql-server-ver15 ``` When binary SQL data is converted...

yeah it's not that the bits on the wire are wrong somehow, it's just a matter of end user expectations for rendering such as the scenarios of printing out query...

they fail the same way with `-cpu 4`. It seems to happen while establishing the connection Running the tests individually fail as well, not just when run en masse. ![image](https://user-images.githubusercontent.com/2224906/125846937-69bd6d76-a215-45d7-b94f-f08b56f49dde.png)

could it be that 200 ms isn't long enough to establish the connection and the test is assuming that it is? If I bump up the wait to 1500 ms...

would you recommend we just increase the timeout in the test or is it worthwhile to revisit the logic in tokenProcessor.nextToken not to send attention if we aren't logged in...

Is the timeout parameter on the context.WithTimeout call also applied to the underlying network connection? If I remove the attention/cancel wait from this code path, the connect fails differently: ```go...

It looks like the dialer sets its own deadline to the Context's deadline and returns an [OpError](https://github.com/golang/go/blob/ed5ebd32b3b8f66515522e8f09bc9dc023c0901c/src/net/dial.go#L530) that wraps a [net error](https://github.com/golang/go/blob/ed5ebd32b3b8f66515522e8f09bc9dc023c0901c/src/net/net.go#L421) I don't see a deterministic way to predict...