Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support for any database/sql implementation #17

Open
javaducky opened this issue Apr 20, 2022 · 6 comments
Open

Support for any database/sql implementation #17

javaducky opened this issue Apr 20, 2022 · 6 comments

Comments

@javaducky
Copy link
Contributor

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
Copy link
Contributor Author

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

@imiric
Copy link
Contributor

imiric commented Apr 21, 2022

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
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Contributor Author

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
Copy link

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?

This was referenced Nov 21, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants