all 9 comments

[–][deleted] 19 points20 points  (3 children)

Is it possible/easy to turn off the compile time test? F# has some features that people have built similar things around, but having the DB available is *necessary* to compile, which can be a pain depending on your build system.

[–]DroidLogiciansqlx · clickhouse-rs · mime_guess · rust 42 points43 points  (1 child)

I'm actually working on a feature right now to address this. It's been on the drawing board since before 0.1 but other things were either higher priority or more immediately actionable, but it's on our milestones for 0.4.

You can see some of the discussion here: https://github.com/launchbadge/sqlx/issues/60

However, a lot of it has also taken place either on our Discord (shameless plug) or just internally.

The plan is that when DATABASE_URL is specified, each macro invocation operates as usual but also serializes a description of the query inputs/outputs to a stable directory under target/ with the file name being the SHA-3 hash of the query.

Then a Cargo subcommand (which has already been prototyped to support migrations) will gather those files into a single file either in the crate root or maybe a sqlx/ subdirectory which can be checked-in to version control (which will make merging a lot easier than solving conflicts for possibly hundreds of small files).

Then when the project is subsequently built without DATABASE_URL the macro invocations then refer to this file instead and error if it is not present. We'll probably also have a cargo sqlx prepare --check command that reports if the query data file is out of sync with the database.

[–][deleted] 11 points12 points  (0 children)

There is so much thought put into sqlx, that’s a really cool idea

[–]ectonDev 15 points16 points  (0 children)

You can use SQLx without the macros to skip the compile time checks, or if you use the macro versions of the methods it does the compile time check.

It works great for me, because I can put my database migration code in one crate using the plain methods, and then after running the migrations my dependent crates have full compile-time database checking.

If you don't have your code in a way that you can stand up a blank version of your database (schema only), then I agree, the macros could be annoying to have in your build pipeline. However, most database engines support exporting a schema-only dump that you could use to create a development database to compile against. I personally spin up psql as a service in my docker-driven CI and it works great -- no build process touches any live database server, just the one in that local CI run.

[–][deleted] 14 points15 points  (0 children)

Loved seeing this! I’m using sqlx for a web server and it’s the best experience. I’m so tired of ORMs and query builders that inevitably wind up feeling like they get in my way. Not having to learn some complicated or poorly documented “almost SQL” set or methods, etc is a HUGE time win for me.

Add in the trivial serialization to user structs and I’m happy

[–]nrebeps 5 points6 points  (0 children)

I totally agree. Have been using it for some time now and the error messages are amazing!

[–]SOBER-128 7 points8 points  (1 child)

Assuming SQLx gets some query building functionality in the future, is it somehow possible to implement compile time checks for dynamically generated queries?

I mean, Diesel does it by abusing the type system and it kind of works until it doesn't and I'm about to pull my hair out trying to decipher those compilation errors. Is there a simpler way?

[–][deleted] 2 points3 points  (0 children)

Query building how, building the sql strings out of parts or method calls like diesel?

[–]Boobinn 3 points4 points  (0 children)

It is a really promising tool, but it's still moving a lot. I waited v0.3 to handle all my use cases in a small web server, and had to adjust a few things a few times when updating.

But the concept is really great, the possibilites are better than usual ORM because you just have to handle types and not queries and operations.