Support for any database/sql implementation

[javaducky]

Go's database/sql abstraction layer allows for a common API provided by many SQL drivers. At the moment, we are limiting this to 4 specific dialects (mysql, postgres, sqlite, and sqlserver) due to the need to include the driver code for each within our extended k6 build.

Ideally, we provide some sort of build option to allow the inclusion of the desired dialect(s) when creating the extended k6 version. Similar to the process followed by xk6, this would dynamically pull driver code into the source, updating import statements as necessary, then build the project with the new drivers. This would be better than having separate xk6-sql-*, repositories only differing by driver code.

[javaducky]

There has been interest for other databases as evidenced by #11.

[imiric]

As discussed over Slack, I don't think this project should aim to support any database/sql implementation. These 4 were chosen as the most popular ones, and as evidenced by #11, it's fairly trivial for users (i.e. developers) to add support for others in their own forks.

Since xk6 alone couldn't handle this build scenario, we can probably hack something up in a Dockerfile that does it. That said, I would argue that anyone who finds the current manual way of adding support for other RDBMSs difficult, would also find using Docker difficult, so I don't see how helpful automating that process would be.

In that Slack discussion @mstoykov brought up the possibility of extensions having extensions (xxk6? 😄), in which case we could split up even the current mysql, postgres, etc. support into sub-extensions and offer new ones in the same way. But doing this in a generic way would be difficult, and coming up with use cases other than for xk6-sql makes it difficult to justify working on it.

[mstoykov]

As a note - there is no real need for any new tool or something in xk6 AFAIK.

The only change is that

xk6-sql/sql.go

Line 33 in b0a243a

supportedDatabases := []string{"mysql", "postgres", "sqlite3", "sqlserver"}

will need to be done through RegisterModule like function - RegisterSQLImplementation and that will need to be called by xk6-sql-mysql to regsiter itself in the xk6-sql at which point xk6 build --with=path/to/xk6-sql-mysql shall suffice - you will just import it through k6/x/sql.

Now to be honest - I would argue this just means that we could as well not have xk6-sql and just have xk6-sql-mysql and so on. And those to use lib-xk6-sql if there is anything that really needs to be shared as an implementation.

[javaducky]

Agreed, but having many more xk6-sql-* repos was the thing I was hoping to avoid; while being simple to put together, it's more of a hassle to manage all these additional repos. If we could have the ability to pull any driver you like, seemed nice to have. 🤷

[javaducky]

As for a having extensions depend upon extensions, I had brought that up when we were discussing the potential need for a Custom Integration Engineer position. E.g. the xk6-chaos somewhat somewhat created similar functionality to the xk6-kubernetes when it would be nice if xk6-chaos were able to extend xk6-kuberenetes. When discussed, extensions being dependent upon other extensions was considered undesirable.

[MerisStupar]

Hello guys,
I hope so that you are up to date with k6 and SQL, I've problem with K6 and Oracle DB. I have followed the instructions but got this error:

ERRO[0000] GoError: database oracle is not supported
at reflect.methodValueCall (native)
at file:///C:/TDM-GCC-64/testOracle/proba.js:3:20(39) hint="script exception"

Any work around?

[szkiba]

Modularization takes into account and at the same time makes this issue obsolete.