pgtyped icon indicating copy to clipboard operation
pgtyped copied to clipboard

Allow providing DB schema instead of querying a dummy database for it

Open jameshfisher opened this issue 3 years ago • 5 comments

First - I love this library! It looks like the only one that actually lets me write plain SQL but with type safety! For me, this is the killer feature of this library.

But PgTyped also sells itself on another feature: "No need to map or translate your DB schema to TypeScript, PgTyped automatically generates types and interfaces for your SQL queries by using your running Postgres database as the source of type information."

That might be what others want, but I actually want to define my DB schema in TypeScript. This is the feature I'm requesting: a way to, instead of providing DB connection details, instead provide a schema definition for type-checking to use.

Reasons I want this:

  • There are constraints in my database that are not expressed in the database schema. For example, I have columns of type jsonb, but the contents here follow a strict JSON schema that PgTyped cannot know about by just looking at the DB.
  • I want to have an in-repo definition of what the database should look like. My dodgy development DB should not be the authority on this.
  • I don't want the build process to depend on a database connection. Everything necessary for the build should be in the repo. Potentially, there should be a deploy-time check that the configured database matches the in-repo schema definition, although that's another story.

jameshfisher avatar Jan 17 '22 17:01 jameshfisher

I had a quick look at the source around here. I think I'm asking for a way to provide my own TypeData instead of using getTypeData.

jameshfisher avatar Jan 17 '22 17:01 jameshfisher

Compare sqlc, a similar library for Golang:

sqlc needs to know your database schema and queries. In the same directory, create a file named schema.sql with the following contents ...

This is similar to what I'm requesting. (Though would not solve the "additional type constraints" issue.)

jameshfisher avatar Jan 17 '22 18:01 jameshfisher

+1

waseemshahwan avatar Jan 24 '22 22:01 waseemshahwan

This would be a gigantic architectural shift for this library. This library doesn't really know anything about your DB schema, instead it's leveraging PostgreSQL's prepared statements to ask for type information from the database itself. I'd be interested to know the strategy sqlc takes, I assume it's fundamentally different if it doesn't spin up a database?

bradleyayers avatar Feb 25 '22 07:02 bradleyayers

Thanks for the kind words @jameshfisher. Unfortunately, pgTyped can't do query analysis by itself for now, it offloads that to Postgres.

I want to have an in-repo definition of what the database should look like. My dodgy development DB should not be the authority on this.

I understand it might be a bit frustrating, but for now you can put a DB schema dump in your repo and use docker to spin up the DB as part of the build process.

@bradleyayers

I'd be interested to know the strategy sqlc takes, I assume it's fundamentally different if it doesn't spin up a database?

It looks like sqlc went the hard route of implementing a database schema and query analysis engine. It is quite impressive what they have achieved. Can't speak on the quality of their query analysis unfortunately, especially on complicated queries. It would be great if postgres would just do proper type inference in the engine without requiring library authors to build their own parsing engines.

adelsz avatar Apr 27 '22 20:04 adelsz