Skip to content
This repository has been archived by the owner on Apr 25, 2023. It is now read-only.

SQLx #138

Open
3 tasks
pimeys opened this issue Jun 3, 2020 · 1 comment
Open
3 tasks

SQLx #138

pimeys opened this issue Jun 3, 2020 · 1 comment
Assignees
Labels
kind/improvement An improvement to existing feature and code. tech/engines Issue for tech Engines.
Milestone

Comments

@pimeys
Copy link
Contributor

pimeys commented Jun 3, 2020

While I've been considering our shift from separate SQL crates to SQLx, our recent move to a different runtime (async-std) adds another reason to consider it as the interface to the open source databases in Quaint.

What is SQLx?

  • A standardized interface to several SQL databases.
  • Connectors for PostgreSQL, MySQL and SQLite
  • Parameter conversion to the underlying databases
  • Written in Rust, no unsafe code

Points to consider for using it:

  • Would allow us to use async-std without running a separate tokio runtime in Prisma (speed, simplicity)
  • Would give us statement caching (configurable) for all three databases
  • Would reduce the amount of code in Quaint (no need to maintain separate conversion and connection setup)
  • Would give us an easy access to new databases when SQLx gets support

Prisma is anyhow stuck now with old version of Tokio due to their latest runtime performing really bad with MySQL. QE is also now ran on top of async-std so we could benefit from the Tide HTTP server and to get Unix pipe and Windows named pipe support in the near future. Due to our database crates being based on Tokio, this means we still need an extra Tokio runtime for database actions, which adds to our memory usage and which might cause trouble in the future (more moving parts).

It also helps to have one of the async-std authors in the house (yay).

What would be the work items to get this done?

With the upcoming change to support SQL Server, and the upcoming change on Tiberius to be runtime-independent, we could then make Quaint to support both: Tokio and async-std with a feature flag (#152).

@pimeys pimeys added the kind/improvement An improvement to existing feature and code. label Jun 3, 2020
@pimeys
Copy link
Contributor Author

pimeys commented Jun 3, 2020

One more point why this would make sense:

Errors would be the same. Now there are differences, such as not being able to execute queries without an error with SQLite if the queries return results. This works with my and pg, which is annoying when sqlite is not doing the same.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
kind/improvement An improvement to existing feature and code. tech/engines Issue for tech Engines.
Projects
None yet
Development

No branches or pull requests

2 participants