Skip to content

Commit 0d32dbe

Browse files
docs: Update managed databases doc to discuss codegen (#2897)
1 parent 01947a6 commit 0d32dbe

File tree

4 files changed

+81
-19
lines changed

4 files changed

+81
-19
lines changed

docs/howto/managed-databases.md

Lines changed: 76 additions & 14 deletions
Original file line numberDiff line numberDiff line change
@@ -6,19 +6,24 @@ Managed databases are powered by [sqlc Cloud](https://dashboard.sqlc.dev). Sign
66

77
*Added in v1.22.0*
88

9-
`sqlc` can create and maintain hosted databases for your project. These
10-
databases are immediately useful for linting queries with [`sqlc vet`](vet.md)
11-
if your lint rules require a connection to a running database. PostgreSQL
12-
support is available today, with MySQL on the way.
13-
14-
This feature is under active development, and we're interested in supporting
15-
other use-cases. Beyond linting queries, you can use sqlc managed databases
16-
in your tests to quickly stand up a database per test suite or even per test,
9+
`sqlc` can create and maintain short-lived hosted databases for your project.
10+
These ephemeral databases are immediately useful for powering sqlc's
11+
database-connected query analyzer, an opt-in feature that improves upon sqlc's
12+
built-in query analysis engine. PostgreSQL support is available today, with
13+
MySQL on the way.
14+
15+
Once configured, `sqlc` will also use managed databases when linting queries
16+
with [`sqlc vet`](vet.html) in cases where your lint rules require a connection
17+
to a running database.
18+
19+
Managed databases are under active development, and we're interested in
20+
supporting other use-cases. Outside of sqlc itself, you can use our managed
21+
databases in your tests to quickly stand up a database per test suite or even per test,
1722
providing a real, isolated database for a test run. No cleanup required.
1823

1924
## Configuring managed databases
2025

21-
To configure `sqlc` to use a managed database, remove the `uri` key from your
26+
To configure `sqlc` to use managed databases, remove the `uri` key from your
2227
`database` configuration and replace it with the `managed` key set to `true`.
2328
Set the `project` key in your `cloud` configuration to the value of your
2429
project ID, obtained via the [dashboard](https://dashboard.sqlc.dev).
@@ -35,7 +40,7 @@ sql:
3540
managed: true
3641
```
3742
38-
## Authentication
43+
### Authentication
3944
4045
`sqlc` expects to find a valid auth token in the value of the `SQLC_AUTH_TOKEN`
4146
environment variable. You can create an auth token via the [dashboard](https://dashboard.sqlc.dev).
@@ -44,13 +49,38 @@ environment variable. You can create an auth token via the [dashboard](https://d
4449
export SQLC_AUTH_TOKEN=sqlc_xxxxxxxx
4550
```
4651

52+
## Improving codegen
53+
54+
Without a database connection, sqlc does its best to parse, analyze and compile your queries just using
55+
the schema you pass it and what it knows about the various database engines it supports. In many cases
56+
this works just fine, but for more advanced queries sqlc might not have enough information to produce good code.
57+
58+
With managed databases configured, `sqlc generate` will automatically create a hosted ephemeral database with your
59+
schema and use that database to improve its query analysis. And sqlc will cache its analysis locally
60+
on a per-query basis to speed up future codegen runs. Here's a minimal working configuration:
61+
62+
```yaml
63+
version: '2'
64+
cloud:
65+
project: '<PROJECT_ID>'
66+
sql:
67+
- schema: schema.sql
68+
queries: query.sql
69+
engine: postgresql
70+
database:
71+
managed: true
72+
gen:
73+
go:
74+
out: "db"
75+
```
76+
4777
## Linting queries
4878

49-
With managed databases configured, `sqlc vet` will create a database with your
50-
package's schema and use that database when running lint rules that require a
51-
database connection, e.g. any [rule relying on `EXPLAIN ...` output](vet.md#rules-using-explain-output).
79+
With managed databases configured, `sqlc vet` will automatically create a hosted ephemeral database with your
80+
schema and use that database when running lint rules that require a
81+
database connection, e.g. any [rule relying on `EXPLAIN ...` output](vet.html#rules-using-explain-output).
5282

53-
If you don't yet have any vet rules, the [built-in sqlc/db-prepare rule](vet.md#sqlc-db-prepare)
83+
If you don't yet have any vet rules, the [built-in sqlc/db-prepare rule](vet.html#sqlc-db-prepare)
5484
is a good place to start. It prepares each of your queries against the database
5585
to ensure the query is valid. Here's a minimal working configuration:
5686

@@ -67,3 +97,35 @@ sql:
6797
rules:
6898
- sqlc/db-prepare
6999
```
100+
101+
## With other tools
102+
103+
With managed databases configured, `sqlc createdb` will create a hosted ephemeral database with your
104+
schema and write the database's connection URI as a string to standard output (stdout). This allows you to use
105+
ephemeral databases with other tools that understand database connection strings.
106+
107+
In the simplest case, you can use psql to poke around:
108+
109+
```shell
110+
psql $(sqlc createdb)
111+
```
112+
113+
Or if you're tired of waiting for us to resolve https://github.com/sqlc-dev/sqlc/issues/296,
114+
you can create databases ad hoc to use with pgtyped:
115+
116+
```shell
117+
DATABASE_URL=$(sqlc createdb) npx pgtyped -c config.json
118+
```
119+
120+
Here's a minimal working configuration if all you need to use is `sqlc createdb`:
121+
122+
```yaml
123+
version: '2'
124+
cloud:
125+
project: '<PROJECT_ID>'
126+
sql:
127+
- schema: schema.sql
128+
engine: postgresql
129+
database:
130+
managed: true
131+
```

docs/howto/rename.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -84,4 +84,4 @@ type Writer struct {
8484
## Limitations
8585

8686
Rename mappings apply to an entire package. Therefore, a column named `foo` and
87-
a table name `foo` can't be renamed different values.
87+
a table name `foo` can't map to different rename values.

docs/howto/structs.md

Lines changed: 1 addition & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -50,4 +50,4 @@ type Author struct {
5050

5151
## More control
5252

53-
See the Type Overrides section of the Configuration File docs for fine-grained control over struct field types and tags.
53+
See the guide to [Overriding types](./overrides.md) for fine-grained control over struct field types and tags.

docs/reference/config.md

Lines changed: 3 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -173,9 +173,9 @@ The `gen` mapping supports the following keys:
173173
- `overrides`:
174174
- It is a collection of definitions that dictates which types are used to map a database types.
175175

176-
##### `overrides`
176+
##### overrides
177177

178-
See [Overriding types](../howto/overrides.md) for in-depth guide to using type overrides. Each mapping of the `overrides` collection has the following keys:
178+
See [Overriding types](../howto/overrides.md) for an in-depth guide to using type overrides. Each mapping of the `overrides` collection has the following keys:
179179

180180
- `db_type`:
181181
- The PostgreSQL or MySQL type to override. Find the full list of supported types in [postgresql_type.go](https://github.com/sqlc-dev/sqlc/blob/main/internal/codegen/golang/postgresql_type.go#L12) or [mysql_type.go](https://github.com/sqlc-dev/sqlc/blob/main/internal/codegen/golang/mysql_type.go#L12). Note that for Postgres you must use the pg_catalog prefixed names where available. Can't be used if the `column` key is defined.
@@ -318,7 +318,7 @@ rules:
318318
query.cmd == "exec"
319319
```
320320

321-
### global overrides
321+
### Global overrides
322322

323323
Sometimes, the same configuration must be done across various specifications of
324324
code generation. Then a global definition for type overriding and field

0 commit comments

Comments
 (0)