Generating types gives unhelpful type definitions

[kopi-cloud]

I was very happy to see Supabase's support for generating types based on the schema definition described in the doco.

But when I tried it out, the result was very disappointing.

Give a table defined like this:

create table public.welcome (
  id text constraint welcome_pkey primary key,
  value bigint not null
);

The end result is:

export interface definitions {
  ...
  /**
   * data for the welcome screen
   */
  welcome: { [key: string]: any };
}

I was expecting something more like:

export type welcome {
  id: string,
  value: number,
}

I don't know much about Swagger/OpenAPI, but it seems like the definition being generated from the /rest/v1/ endpoint doesn't contain the structure of the table objects, for example the welcome definition is just:

    "welcome": {
      "description": "data for the welcome screen",
      "type": "object"
    }

Am I doing something wrong? Is there some config or a flag I need to set to make the swagger endpoint generate more info?

I've attached the full swagger document.

[talolard]

Hi,
Building on this and possibly hijacking (sorry if...)

We're heavy postgrest users, and autogenerated and typed client libraries would be amazing.
For our non postgrest needs we've used openapi-client-axios which generates type definitions and a typed client library.
Unfortunately it works on openapi3 and postgrest is on openapi2 and getting a useful client has proven challenging.

We've been thinking of paying the maintainer of openapi-client-axios to make a similar library specifically for postgrest, would the Supabase team want to join ?

[kiwicopple]

Hey @talolard - the axios client looks interesting.

Our end goal for the type generation will skip the swagger/OpenApi completely though. Instead we will generate it straight from the database - there is too much information lost between the database and the OpenApi spec.

This is (one of) the reasons we're building up the postgres-api

[kopi-cloud]

@kiwicopple I just tried this in a different supabase project and it seems to be working properly there.
Have sent details of working project to the beta address.

[kopi-cloud]

Ok - it looks like this is my fault.

I'm using a product called Flyway to do schema migrations, and the supabase project that has problems is used as my continuous integration DB. As such, I run the flyway clean command on it as part of my test pipeline. I think the clean command has deleted objects in the public schema that supabase expects to be there.

Oops, my bad.

[kiwicopple]

No probs @kopi-cloud !

[kopi-cloud]

I used a brand new project to verify that my pipeline works properly from creating tables via migrations to generating swagger definitions through to generating types with proper field definitions - so it does work.

But, of course, I messed up my code and accidentally stomped the public schema again. It would be convenient (if somewhat dangerous for a production dataset) if there was some way to reset the DB to a state of "empty + supabase stuff". Unless you can suggest an alternate approach, I'm going to have to create a new SB project and re-configure all the postgres:// and https:// config in dev each time I do that.

[kiwicopple]

We'll add Point in Time backups in the future - the easiest way is to do a pg_dump of your database before you start making changes, then if anything goes awry you can run a restore to overwrite your changes