Prepared Statements and Context

[SchumacherFM]

hey guys,

your driver has sparked my interest and its general performance is outstanding. 👏
I would like to use it in an huge ecommerce project with over 350 tables and millions of rows.
But I'm missing features like prepared statements and context.Context integration for cancelling.
What are you plans about implementing them?

TIA

[bruwozniak]

Hi @SchumacherFM

Thanks for you interest in the project.
At the moment we don't have an urgent need for those features in production systems, however we agree that it would be nice to have them, and so we are planning to add them at some point.
Unfortunately we can't commit to any timeline, although we might find a day or two in the upcoming weeks.

Also, as this is an open source project, PRs are most definitely welcome 😉

Kind regards from Berlin

[SchumacherFM]

Thanks for an answer Bruno :-) I'm willing to help. Regarding prepared statement: Are there also changes needed in the package https://github.com/pubnative/mysqlproto-go ? Or are prepared statements only an on-top feature of this package?
Implementing context seems a no-brainer ;-)
Greetings from Zurich

[bruwozniak]

Yes, you are correct: it's necessary to add the support for the statements in the protocol package/repo.
Context would likely be a smaller change, and so it's more likely to be added first from our side.

[kostyantyn]

@SchumacherFM we allocated some time to understand how easy to integrate context.Context and noticed Go itself doesn't support it for reading and writing from net.TCPConn or net.UDPConn

Since we have to handle the timeout and cancellation ourselves, it will take us some time to add it. Currently reviewing the best approach to do it.

In meanwhile, we added context.Context for obtaining a TCP connection. #5

Will keep you posted about the status of both features.

[SchumacherFM]

Cool. Thanks for the progress. I've taken a deeper look into context.Context in database/sql, it looks trivial at the first sight but more complex on the second sight. What would be nice (and I don't know if that's working) when you can cancel a query to let the MySQL server know that it can stop the processing. There is a possibility to do it via a time out MAX_EXECUTION_TIME but that seems hacky.

[kostyantyn]

MAX_EXECUTION_TIME is a good option but it won't prevent you from the case when a TCP connection got forcibly closed.

We are considering to check context.Context status (canceled or timed out) when we do non-blocking reading or writing from the connection. If it expired, we would close the connection. We see something similar is net/transport is doing.