Introducing a standard interface for database drivers

[halvardssm]

In the JS ecosystem for database drivers, this package is one of the more widely used. Together with the Deno Standard Library team, we have been working on creating a standard interface for JS that database drivers can adopt to provide consistency in how to interact with sql based databases, similar to what exists for the Go ecosystem.

In the JS community, we are quite wary of any breaking changes, or alterations of existing signatures, which is why this would not require a rewrite of existing code, but can live alongside the existing implementations. If the interface is adopted into the project, it is possible and also encouraged to provide both the existing exports alongside the new exports to allow for gradual adoption.

I am opening this issue to introduce the project, and to hopefully spark interest from the maintainer team to engage, contribute and potentially adopt the interfaces into this package. The current implementation of the standard interface is more or less stable, but if any overlooked issues or concerns surface, the implementation is open for amendments. I am also happy to provide implementation support if it helps adoption.

If this project is of interest to you, feel free to read the full specifications in the RFC PR, and comment here or in the RFC. And feel free to reach out if a further discussion is wanted.

Issues has been created for other popular db driver packages, and existing implementations can be found for the following drivers:

• Deno SQLite: Implemented stdext/sql interfaces denodrivers/sqlite3#135
• Deno MySQL: Implement SQLx interface denodrivers/mysql#170

[mceachen]

@halvardssm FYI I’m just a maintainer here, not the author of this library. Some thoughts:

Standards are great, and support much less friction for switching between libraries, but:

1. Opening issues across 7 wholly unrelated projects might not earn the compliance that your were hoping for: I’d suggest starting discussions, rather than issues, so each library community can discuss and decide what they are willing and able to offer.

2. I’d also expect substantial pushback, especially when it’s changing an API that they have probably spent a ton of time and effort in crafting, supporting, using, and improving over many years.

3. I’ve worked on database drivers and compatibility layers at more than a handful of companies over the last 30 years, and this sort of flexibility (like what ODBC and JDBC professed so many years ago) has surprisingly not been the big win I thought it would be. Anecdotally, I’ve never witnessed a company switch production databases, and this common-interface-for-everything opens more pitfalls than I initially expected, as the API may suggest support of features that doesn’t match the underlying RDBMS

[halvardssm]

Hi @mceachen ! Thanks for your input!

To cover your concerns:

1. The project has been planned for a while and community feedback has been requested along the way. The reason why issues has been created across all the different repos is to get some final feedback from the maintainers of the drivers for the implementation before the initial release.
2. I think it's important to clarify that the standardised interface can live alongside the existing apis, it is fully possible to wrap around the existing API and export them both from the package. Therefore pushback should (hopefully) not be too bad
3. It is not as much about being able to switch for you application, but it is about the developer experience so that you can have an expectation of how to connect and query databases across projects using different databases. Regarding the pitfalls, are there any learnings you could share that we could avoid? I also want to mention that these interfaces are not restrictive, so that respective db methods can be added as long as the method name does not clash with the methods in the interface names.

I hope this cleared up some of your concerns, but feel free to let me know if there is anything else!