sqlc-dev/sqlc (github.com/sqlc-dev/sqlc)
### [`v1.24.0`](https://togithub.com/sqlc-dev/sqlc/releases/tag/v1.24.0)
[Compare Source](https://togithub.com/sqlc-dev/sqlc/compare/v1.23.0...v1.24.0)
#### What's new
##### Verifying database schema changes
Schema updates and poorly-written queries often bring down production databases. That’s bad.
Out of the box, `sqlc generate` catches some of these issues. Running `sqlc vet` with the `sqlc/db-prepare` rule catches more subtle problems. But there is a large class of issues that sqlc can’t prevent by looking at current schema and queries alone.
For instance, when a schema change is proposed, existing queries and code running in production might fail when the schema change is applied. Enter `sqlc verify`, which analyzes existing queries against new schema changes and errors if there are any issues.
Let's look at an example. Assume you have these two tables in production.
```sql
CREATE TABLE users (
id UUID PRIMARY KEY
);
CREATE TABLE user_actions (
id UUID PRIMARY KEY,
user_id UUID NOT NULL,
action TEXT,
created_at TIMESTAMP
);
```
Your application contains the following query to join user actions against the users table.
```sql
-- name: GetUserActions :many
SELECT * FROM users u
JOIN user_actions ua ON u.id = ua.user_id
ORDER BY created_at;
```
So far, so good. Then assume you propose this schema change:
```sql
ALTER TABLE users ADD COLUMN created_at TIMESTAMP;
```
Running `sqlc generate` fails with this change, returning a `column reference "created_at" is ambiguous` error. You update your query to fix the issue.
```sql
-- name: GetUserActions :many
SELECT * FROM users u
JOIN user_actions ua ON u.id = ua.user_id
ORDER BY u.created_at;
```
While that change fixes the issue, there's a production outage waiting to happen. When the schema change is applied, the existing `GetUserActions` query will begin to fail. The correct way to fix this is to deploy the updated query before applying the schema migration.
It ensures migrations are safe to deploy by sending your current schema and queries to sqlc cloud. There, we run the queries for your latest push against your new schema changes. This check catches backwards incompatible schema changes for existing queries.
Here `sqlc verify` alerts you to the fact that ORDER BY "created_at" is ambiguous.
```sh
$ sqlc verify
FAIL: app query.sql
=== Failed
=== FAIL: app query.sql GetUserActions
ERROR: column reference "created_at" is ambiguous (SQLSTATE 42702)
```
By the way, this scenario isn't made up! It happened to us a few weeks ago. We've been happily testing early versions of `verify` for the last two weeks and haven't had any issues since.
This type of verification is only the start. If your application is deployed on-prem by your customers, `verify` could tell you if it's safe for your customers to rollback to an older version of your app, even after schema migrations have been run.
##### Rename `upload` command to `push`
We've renamed the `upload` sub-command to `push`. We changed the data sent along in a push request. Upload used to include the configuration file, migrations, queries, and all generated code. Push drops the generated code in favor of including the [plugin.GenerateRequest](https://buf.build/sqlc/sqlc/docs/main:plugin#plugin.GenerateRequest), which is the protocol buffer message we pass to codegen plugins.
We also add annotations to each push. By default, we include these environment variables if they are present:
GITHUB_REPOSITORY
GITHUB_REF
GITHUB_REF_NAME
GITHUB_REF_TYPE
GITHUB_SHA
Like upload, `push` should be run when you tag a release of your application. We run it on every push to main, as we continuously deploy those commits.
##### MySQL support in `createdb`
The `createdb` command, added in the last release, now supports MySQL. If you have a cloud project configured, you can use `sqlc createdb` to spin up a new ephemeral database with your schema and print its connection string to standard output. This is useful for integrating with other tools. Read more in the [managed databases](../howto/managed-databases.md#with-other-tools) documentation.
##### Plugin interface refactor
This release includes a refactored plugin interface to better support future functionality. Plugins now support different methods via a gRPC service interface, allowing plugins to support different functionality in a backwards-compatible way.
By using gRPC interfaces, we can even (theoretically) support [remote plugins](https://togithub.com/sqlc-dev/sqlc/pull/2938), but that's something for another day.
##### New Contributors
- [@xeraph-dev](https://togithub.com/xeraph-dev) made their first contribution in [https://github.com/sqlc-dev/sqlc/pull/2924](https://togithub.com/sqlc-dev/sqlc/pull/2924)
- [@bilalmirza74](https://togithub.com/bilalmirza74) made their first contribution in [https://github.com/sqlc-dev/sqlc/pull/2931](https://togithub.com/sqlc-dev/sqlc/pull/2931)
- [@hawkingrei](https://togithub.com/hawkingrei) made their first contribution in [https://github.com/sqlc-dev/sqlc/pull/2943](https://togithub.com/sqlc-dev/sqlc/pull/2943)
- [@iamwavecut](https://togithub.com/iamwavecut) made their first contribution in [https://github.com/sqlc-dev/sqlc/pull/2955](https://togithub.com/sqlc-dev/sqlc/pull/2955)
- [@eduardolat](https://togithub.com/eduardolat) made their first contribution in [https://github.com/sqlc-dev/sqlc/pull/2995](https://togithub.com/sqlc-dev/sqlc/pull/2995)
**Full Changelog**: https://github.com/sqlc-dev/sqlc/compare/v1.23.0...v1.24.0
Configuration
📅 Schedule: Branch creation - "before 4am" (UTC), Automerge - At any time (no schedule defined).
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
[ ] If you want to rebase/retry this PR, check this box
This PR has been generated by Mend Renovate. View repository job log here.
This PR contains the following updates:
v1.23.0->v1.24.0Release Notes
sqlc-dev/sqlc (github.com/sqlc-dev/sqlc)
### [`v1.24.0`](https://togithub.com/sqlc-dev/sqlc/releases/tag/v1.24.0) [Compare Source](https://togithub.com/sqlc-dev/sqlc/compare/v1.23.0...v1.24.0) #### What's new ##### Verifying database schema changes Schema updates and poorly-written queries often bring down production databases. That’s bad. Out of the box, `sqlc generate` catches some of these issues. Running `sqlc vet` with the `sqlc/db-prepare` rule catches more subtle problems. But there is a large class of issues that sqlc can’t prevent by looking at current schema and queries alone. For instance, when a schema change is proposed, existing queries and code running in production might fail when the schema change is applied. Enter `sqlc verify`, which analyzes existing queries against new schema changes and errors if there are any issues. Let's look at an example. Assume you have these two tables in production. ```sql CREATE TABLE users ( id UUID PRIMARY KEY ); CREATE TABLE user_actions ( id UUID PRIMARY KEY, user_id UUID NOT NULL, action TEXT, created_at TIMESTAMP ); ``` Your application contains the following query to join user actions against the users table. ```sql -- name: GetUserActions :many SELECT * FROM users u JOIN user_actions ua ON u.id = ua.user_id ORDER BY created_at; ``` So far, so good. Then assume you propose this schema change: ```sql ALTER TABLE users ADD COLUMN created_at TIMESTAMP; ``` Running `sqlc generate` fails with this change, returning a `column reference "created_at" is ambiguous` error. You update your query to fix the issue. ```sql -- name: GetUserActions :many SELECT * FROM users u JOIN user_actions ua ON u.id = ua.user_id ORDER BY u.created_at; ``` While that change fixes the issue, there's a production outage waiting to happen. When the schema change is applied, the existing `GetUserActions` query will begin to fail. The correct way to fix this is to deploy the updated query before applying the schema migration. It ensures migrations are safe to deploy by sending your current schema and queries to sqlc cloud. There, we run the queries for your latest push against your new schema changes. This check catches backwards incompatible schema changes for existing queries. Here `sqlc verify` alerts you to the fact that ORDER BY "created_at" is ambiguous. ```sh $ sqlc verify FAIL: app query.sql === Failed === FAIL: app query.sql GetUserActions ERROR: column reference "created_at" is ambiguous (SQLSTATE 42702) ``` By the way, this scenario isn't made up! It happened to us a few weeks ago. We've been happily testing early versions of `verify` for the last two weeks and haven't had any issues since. This type of verification is only the start. If your application is deployed on-prem by your customers, `verify` could tell you if it's safe for your customers to rollback to an older version of your app, even after schema migrations have been run. ##### Rename `upload` command to `push` We've renamed the `upload` sub-command to `push`. We changed the data sent along in a push request. Upload used to include the configuration file, migrations, queries, and all generated code. Push drops the generated code in favor of including the [plugin.GenerateRequest](https://buf.build/sqlc/sqlc/docs/main:plugin#plugin.GenerateRequest), which is the protocol buffer message we pass to codegen plugins. We also add annotations to each push. By default, we include these environment variables if they are present: GITHUB_REPOSITORY GITHUB_REF GITHUB_REF_NAME GITHUB_REF_TYPE GITHUB_SHA Like upload, `push` should be run when you tag a release of your application. We run it on every push to main, as we continuously deploy those commits. ##### MySQL support in `createdb` The `createdb` command, added in the last release, now supports MySQL. If you have a cloud project configured, you can use `sqlc createdb` to spin up a new ephemeral database with your schema and print its connection string to standard output. This is useful for integrating with other tools. Read more in the [managed databases](../howto/managed-databases.md#with-other-tools) documentation. ##### Plugin interface refactor This release includes a refactored plugin interface to better support future functionality. Plugins now support different methods via a gRPC service interface, allowing plugins to support different functionality in a backwards-compatible way. By using gRPC interfaces, we can even (theoretically) support [remote plugins](https://togithub.com/sqlc-dev/sqlc/pull/2938), but that's something for another day. ##### New Contributors - [@xeraph-dev](https://togithub.com/xeraph-dev) made their first contribution in [https://github.com/sqlc-dev/sqlc/pull/2924](https://togithub.com/sqlc-dev/sqlc/pull/2924) - [@bilalmirza74](https://togithub.com/bilalmirza74) made their first contribution in [https://github.com/sqlc-dev/sqlc/pull/2931](https://togithub.com/sqlc-dev/sqlc/pull/2931) - [@hawkingrei](https://togithub.com/hawkingrei) made their first contribution in [https://github.com/sqlc-dev/sqlc/pull/2943](https://togithub.com/sqlc-dev/sqlc/pull/2943) - [@iamwavecut](https://togithub.com/iamwavecut) made their first contribution in [https://github.com/sqlc-dev/sqlc/pull/2955](https://togithub.com/sqlc-dev/sqlc/pull/2955) - [@eduardolat](https://togithub.com/eduardolat) made their first contribution in [https://github.com/sqlc-dev/sqlc/pull/2995](https://togithub.com/sqlc-dev/sqlc/pull/2995) **Full Changelog**: https://github.com/sqlc-dev/sqlc/compare/v1.23.0...v1.24.0Configuration
📅 Schedule: Branch creation - "before 4am" (UTC), Automerge - At any time (no schedule defined).
🚦 Automerge: Enabled.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.
This PR has been generated by Mend Renovate. View repository job log here.