Workaround for column un-supported settings doesn't work

[gguy0406]

Problem

The workaround for un-supported settings by adding the setting name into the column type name, such as id “bigint unsigned” [pk] doesn't work

Example

Take an example DBML file:

Table Product {
  id integer [increment, pk]
  price "integer check (price > 0)" [not null]
  quantity "integer check(quantity > 0) [default: 0, not null]
}

When I convert that to Postgresql, it looks like:

CREATE TABLE "Product " (
  "id" INTEGER GENERATED BY DEFAULT AS IDENTITY PRIMARY KEY,
  "price" "integer check (price > 0)" NOT NULL,
  "quantity" "integer check (quantity > 0)" NOT NULL DEFAULT 0,
);

Which then throwing error when attempting to execute query pq: type "integer check (totalPrice > 0)" does not exist

[NQPhuc]

Hi,

Currently, there's no way to add check constraint and other unsupported settings so the the export SQL is correctly equivalent.

The work-around is only mean to make the dbml valid. Instead of putting the constraint in the column type, you can try to annotate the constraint in field note, like this:

Table Product {
  id integer [increment, pk]
  price integer [not null, note: "check (price > 0)"]
  quantity integer [default: 0, not null, note: "check (quantity > 0)"]
}

Which will export to Postgresql without error, but you'll have to add the check constraint back mannually.

We'll consider support the CHECK constraint in the future as well, since it is a common problem.