Closed seanlaff closed 7 months ago
Looking further, it seems like the driver dir is a separate implementation from the main server. Perhaps I'd be better off trying something like https://pkg.go.dev/google.golang.org/grpc/test/bufconn as a way to avoid using the host's networking stack- though I'm not sure if I'll be able to thread that through as Handler
is all private
Closing in favor of https://github.com/dolthub/go-mysql-server/pull/2319, which seems like a better approach
If I create an in-memory server and supply
multiStatements=true
in the connection dsn, mutli statements work. However, I have not been able to find a way to reproduce this behavior when using the the in-memory driver directly- is that an expected limitation?My usecase: I have tests that depend on mysql and I'm interested in running an in-memory go-mysql-server in such a way that I wouldn't have to worry about port coordination. I thought I could use the
driver
directly to avoid the networking stack, but maybe I misunderstand the abstractions.I copied the example from
driver/example
(Im usingmain d5876b4
)This test fails- which I assume is expected since I have yet to supply the multiStatements flag. I tried a few variations:
Building a conn from the driver, supplying the multiStatements flag, no luck:
Also tried having my factory implement
SessionBuilder
, and then supplying the rawCapabilities
bit flag directlyalso no luck.
Would anyone be able to point me in the right direction? I am also happy to make a PR if needed. (I have a mysqldump of my db schema which I'm trying to load, as a precursor to tests).