fix(import): keep a column declared NULL nullable

[NgoQuocViet2001]

The bug

Importing SQL that declares a column explicitly nullable turns it into NOT NULL.

CREATE TABLE t (a INT NULL, b INT NOT NULL, c INT);

a is declared NULL, but it arrives in the diagram with the Not null box ticked. The column's nullability is silently inverted, and re-exporting the diagram then emits a INT NOT NULL — so a round-trip through drawDB changes the schema.

Why

node-sql-parser emits a node for both markers, not just for NOT NULL:

a INT NULL      ->  nullable = { type: "null",     value: "null" }
b INT NOT NULL  ->  nullable = { type: "not null", value: "not null" }
c INT           ->  nullable = undefined

The importers tested that node for truthiness:

if (d.nullable) field.notNull = true;

Both markers are truthy objects, so NULL and NOT NULL were treated identically. Only the omitted marker was read correctly, which is why the bug is invisible on the common CREATE TABLE t (c INT) shape.

The fix reads the marker's type instead.

Verified

Ran the real importers through the public importSQL() entry point — the same one EditorHeader/Modal/Modal.jsx calls — with node-sql-parser at the version package-lock.json pins:

column a is declared `INT NULL` -> notNull SHOULD be false

              before                        after
mysql         a=true   b=true  c=false      a=false  b=true  c=false
mariadb       a=true   b=true  c=false      a=false  b=true  c=false
postgresql    a=true   b=true  c=false      a=false  b=true  c=false
transactsql   a=true   b=true  c=false      a=false  b=true  c=false
sqlite        a=true   b=true  c=false      a=false  b=true  c=false

b (NOT NULL) and c (omitted) are unchanged, which is the part that matters — this only stops the explicit NULL marker from being misread.

Scope

Five importers share the same line: mysql, mariadb, mssql, postgres, sqlite.

oraclesql is not affected and is left alone — it already inspects the value (c.constraint.not_null === "not null") rather than the node's truthiness, so it was reading the marker correctly all along.

Checks

• npm run lint — clean (--max-warnings 0).
• npm run build — succeeds.

Both are what .github/workflows/build.yml runs. The repo has no test suite, so there is nowhere to hang a regression test; the reproduction above is a scratch script run against the real modules and is not part of the diff. Happy to add a small test setup separately if you would like one — it seemed wrong to bundle that into a bug fix.

[vercel]

@NgoQuocViet2001 is attempting to deploy a commit to the dottle's projects Team on Vercel.

A member of the Team first needs to authorize it.