Files
drizzle-team--drizzle-orm/changelogs/drizzle-kit/0.26.0.md
T
2026-07-13 12:10:05 +08:00

123 lines
3.6 KiB
Markdown

# New Features
## Checks support in `drizzle-kit`
You can use drizzle-kit to manage your `check` constraint defined in drizzle-orm schema definition
For example current drizzle table:
```ts
import { sql } from "drizzle-orm";
import { check, pgTable } from "drizzle-orm/pg-core";
export const users = pgTable(
"users",
(c) => ({
id: c.uuid().defaultRandom().primaryKey(),
username: c.text().notNull(),
age: c.integer(),
}),
(table) => ({
checkConstraint: check("age_check", sql`${table.age} > 21`),
})
);
```
will be generated into
```sql
CREATE TABLE IF NOT EXISTS "users" (
"id" uuid PRIMARY KEY DEFAULT gen_random_uuid() NOT NULL,
"username" text NOT NULL,
"age" integer,
CONSTRAINT "age_check" CHECK ("users"."age" > 21)
);
```
The same is supported in all dialects
### Limitations
- `generate` will work as expected for all check constraint changes.
- `push` will detect only check renames and will recreate the constraint. All other changes to SQL won't be detected and will be ignored.
So, if you want to change the constraint's SQL definition using only `push`, you would need to manually comment out the constraint, `push`, then put it back with the new SQL definition and `push` one more time.
## Views support in `drizzle-kit`
You can use drizzle-kit to manage your `views` defined in drizzle-orm schema definition. It will work with all existing dialects and view options
### PostgreSQL
For example current drizzle table:
```ts
import { sql } from "drizzle-orm";
import {
check,
pgMaterializedView,
pgTable,
pgView,
} from "drizzle-orm/pg-core";
export const users = pgTable(
"users",
(c) => ({
id: c.uuid().defaultRandom().primaryKey(),
username: c.text().notNull(),
age: c.integer(),
}),
(table) => ({
checkConstraint: check("age_check", sql`${table.age} > 21`),
})
);
export const simpleView = pgView("simple_users_view").as((qb) =>
qb.select().from(users)
);
export const materializedView = pgMaterializedView(
"materialized_users_view"
).as((qb) => qb.select().from(users));
```
will be generated into
```sql
CREATE TABLE IF NOT EXISTS "users" (
"id" uuid PRIMARY KEY DEFAULT gen_random_uuid() NOT NULL,
"username" text NOT NULL,
"age" integer,
CONSTRAINT "age_check" CHECK ("users"."age" > 21)
);
CREATE VIEW "public"."simple_users_view" AS (select "id", "username", "age" from "users");
CREATE MATERIALIZED VIEW "public"."materialized_users_view" AS (select "id", "username", "age" from "users");
```
Views supported in all dialects, but materialized views are supported only in PostgreSQL
#### Limitations
- `generate` will work as expected for all view changes
- `push` limitations:
1. If you want to change the view's SQL definition using only `push`, you would need to manually comment out the view, `push`, then put it back with the new SQL definition and `push` one more time.
## Updates for PostgreSQL enums behavior
We've updated enum behavior in Drizzle with PostgreSQL:
- Add value after or before in enum: With this change, Drizzle will now respect the order of values in the enum and allow adding new values after or before a specific one.
- Support for dropping a value from an enum: In this case, Drizzle will attempt to alter all columns using the enum to text, then drop the existing enum and create a new one with the updated set of values. After that, all columns previously using the enum will be altered back to the new enum.
> If the deleted enum value was used by a column, this process will result in a database error.
- Support for dropping an enum
- Support for moving enums between schemas
- Support for renaming enums