Non-sql support

[tj]

I 100% understand if it's out of scope but it would be cool to have telnet-style protocols so this could be used for redis/influx and friends. I've written a few similar tools to stress test or create a baseline and it's definitely something that could live in a package like this!

Maybe just an interface that implements each step that can be easily wrapped up in a cli for custom cases.

[awreece]

So, dbbench is pretty strongly wed to the golang database/sql standard package right now. While this makes it easy to support anything that implements that package, I don't oppose moving away from this direction for a number of reasons:

• The golang sql.DB package is very opionated and has some quirks. For example, since it strongly encourages the use of a connection pool, intuitive SQL operations like use database or set session-var=value are not really supportable.
• The golang sql.DB is hard to test with (since it is a struct not an interface, it hard for me to inject a testing version of the database). I'm already working to reduce our reliance on this as I'm try to add better testing.
• As I've started adding support for other SQL dialects, I've realized that it is not really tenable to whitelist/blacklist certain types queries (e.g. forbidding session variables, etc). I need to do some restructuring of code before adding more SQL dialects to ensure that there will be easy ways to extend dbbench since I've already hit some limitations in my current structure. Given that I need to support different flavors of SQL, it might make sense to support non-SQL connectors.

If you wanted to contribute to dbbench to get this support in, I'd suggest making/finding a primitive golang sql.Driver that covers subset of functionality you care about. If that doesn't work there are other options, although for now I'll be a bit hesitant to commit to anything that substantially increases the complexity of dbbench or its reliance on non-standard packages.

If you wanted something immediately, tsung is a similar (but substantially more complex) tool that might cover the functionality you need.

[awreece]

I just pushed a diff that abstracted the database specific logic into a DatabaseFlavor and an abstract Database interface. This was intended to make it easier for me to write some more tests, but it might also make it possible to extend dbbench to support redis, etc w/o having to extend the sql.Driver interface.