Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

More information in /schema about column types. #385

Open
divyenduz opened this issue Sep 12, 2024 · 0 comments
Open

More information in /schema about column types. #385

divyenduz opened this issue Sep 12, 2024 · 0 comments
Labels
good first issue Good for newcomers

Comments

@divyenduz
Copy link

divyenduz commented Sep 12, 2024

To better support enums in the frontend, we need some more information in the /schema API, here is an example, this column (Field.usage) is an enum but we have no way of telling it from, say, a custom domain type or custom types from extensions. Eventually, we want to make all types editable from the UI. So, we need the /schema API to return that this is an enum and its possible values for enum's case. This will allow us to build features like dropdown select for enum and/or client side validation for enum value.

Current output:

{
  "schema": {
    "name": "",
    "display_name": "",
    "tables": {
      "Field": {
        "oid": "6526469",
        "name": "Field",
        "comment": "",
        "columns": {
          "usage": {
            "name": "usage",
            "type": "bb_mmco0u98b56618sjl6glp6csh8_d5mrcj.\"FieldUsage\"",
            "default": null,
            "nullable": false,
            "unique": false,
            "comment": ""
          }
        },
        "indexes": {
          "Field_pkey": {
            "name": "Field_pkey",
            "unique": true,
            "columns": ["id"]
          }
        },
        "primaryKey": ["id"],
        "foreignKeys": {},
        "checkConstraints": {},
        "uniqueConstraints": {},
        "xataCompatible": false
      }
    }
  }
}

Potential future output

{
  "schema": {
    "name": "",
    "display_name": "",
    "tables": {
      "Field": {
        "oid": "6526469",
        "name": "Field",
        "comment": "",
        "columns": {
          "usage": {
            "name": "usage",
            "type": "bb_mmco0u98b56618sjl6glp6csh8_d5mrcj.\"FieldUsage\"",
            "default": null,
            "nullable": false,
            "unique": false,
            "comment": "",
            "postgresType": "enum",
            "possibleValues": ["TOP_HALF", "BOTTOM_HALF", "FULL_FIELD"]
          }
        },
        "indexes": {
          "Field_pkey": {
            "name": "Field_pkey",
            "unique": true,
            "columns": ["id"]
          }
        },
        "primaryKey": ["id"],
        "foreignKeys": {},
        "checkConstraints": {},
        "uniqueConstraints": {},
        "xataCompatible": false
      }
    }
  }
}

Other considerations (very hand-wavey)

  1. We can add "checkConstraint" too, which has the PostgreSQL check, e.g. {"checkConstraint": {"length(xata_id) < 256"}}. The frontend can then potentially parse this into a TypeScript validation rule.
  2. Knowing that a type is array, composite, range and their dimensions. Currently, we interpret this in the frontend with some lazy parsing, pgroll should be the source of truth for this information.
  3. Knowing that a type is domain type
  4. Knowing that a type is a custom type
  5. With all these considerations, the output of postgresType can be 'enum' | 'array' | 'range' | 'composite' | 'domain' | 'custom-type'

For the purpose of this ticket, enum is enough.

Related #376

@andrew-farries andrew-farries added the good first issue Good for newcomers label Oct 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

2 participants