litedbmodel 1.0.0 → 1.1.0

package/docs/BENCHMARK.md

@@ -27,52 +27,52 @@ Reference: [Kysely performance comparison article](https://izanami.dev/post/1e3f
 <!--@embedoc:benchmark_table-->
 | Operation | litedbmodel | Kysely | Drizzle | TypeORM | Prisma |
 | --- | --- | --- | --- | --- | --- |
-| Find all (limit 100) | 0.65ms | **0.61ms** 🏆 | **0.61ms** 🏆 | 0.69ms | 1.28ms |
-| Filter, paginate & sort | **0.55ms** 🏆 | 0.57ms | 0.61ms | 0.64ms | 0.95ms |
-| Nested find all (include posts) | 3.57ms | 4.59ms | **3.32ms** 🏆 | 7.63ms | 12.37ms |
-| Find first | 0.35ms | **0.31ms** 🏆 | 0.32ms | 0.33ms | 0.59ms |
-| Nested find first (include posts) | 0.57ms | 0.53ms | 0.58ms | **0.46ms** 🏆 | 0.98ms |
-| Find unique (by email) | 0.29ms | **0.27ms** 🏆 | 0.29ms | 0.32ms | 0.54ms |
-| Nested find unique (include posts) | 0.56ms | **0.50ms** 🏆 | 0.57ms | 0.94ms | 0.88ms |
-| Create | **0.62ms** 🏆 | 0.67ms | 0.69ms | 0.74ms | 0.97ms |
-| Nested create (with post) | 0.91ms | **0.89ms** 🏆 | 0.95ms | 1.15ms | 1.64ms |
-| Update | **0.65ms** 🏆 | 0.66ms | **0.65ms** 🏆 | **0.65ms** 🏆 | 1.11ms |
-| Nested update (update user + post) | **0.86ms** 🏆 | 0.87ms | 0.92ms | 0.95ms | 2.12ms |
-| Upsert | 0.65ms | **0.63ms** 🏆 | 0.67ms | 0.75ms | 1.77ms |
-| Nested upsert (user + post) | **0.87ms** 🏆 | 0.90ms | 0.95ms | 0.98ms | 1.92ms |
-| Delete | **0.85ms** 🏆 | 0.88ms | 0.91ms | 0.96ms | 1.44ms |
-| Create Many (10 records) | 0.68ms | **0.67ms** 🏆 | 0.85ms | 0.91ms | 1.17ms |
-| Upsert Many (10 records) | 0.81ms | **0.80ms** 🏆 | 0.98ms | 1.02ms | 11.34ms |
-| Update Many (10 different values) | **0.75ms** 🏆 | 2.71ms | 2.79ms | 3.05ms | 5.24ms |
-| Nested relations (100→1000→10000) | 26.84ms | 23.74ms | **22.31ms** 🏆 | 75.25ms | 83.91ms |
-| Nested relations (composite key, 5 tenants) | 23.38ms | N/A | **15.75ms** 🏆 | 37.72ms | 214.51ms |
+| Find all (limit 100) | 0.70ms | 0.65ms | **0.64ms** 🏆 | 0.72ms | 1.35ms |
+| Filter, paginate & sort | **0.58ms** 🏆 | 0.64ms | 0.59ms | 0.66ms | 1.10ms |
+| Nested find all (include posts) | **3.64ms** 🏆 | 4.60ms | 4.66ms | 8.34ms | 12.06ms |
+| Find first | 0.37ms | **0.32ms** 🏆 | 0.36ms | 0.40ms | 0.59ms |
+| Nested find first (include posts) | 0.65ms | 0.61ms | 0.71ms | **0.52ms** 🏆 | 1.06ms |
+| Find unique (by email) | **0.29ms** 🏆 | 0.31ms | 0.30ms | 0.32ms | 0.53ms |
+| Nested find unique (include posts) | **0.57ms** 🏆 | 0.58ms | 0.59ms | 1.05ms | 0.94ms |
+| Create | 0.69ms | **0.68ms** 🏆 | 0.76ms | 0.79ms | 1.01ms |
+| Nested create (with post) | **0.90ms** 🏆 | 0.96ms | 1.03ms | 1.22ms | 1.81ms |
+| Update | 0.63ms | **0.61ms** 🏆 | 0.66ms | 0.67ms | 1.12ms |
+| Nested update (update user + post) | 0.94ms | 1.00ms | **0.92ms** 🏆 | 1.02ms | 2.28ms |
+| Upsert | 0.71ms | 0.74ms | **0.66ms** 🏆 | 0.75ms | 2.07ms |
+| Nested upsert (user + post) | **1.00ms** 🏆 | **1.00ms** 🏆 | **1.00ms** 🏆 | 1.14ms | 2.27ms |
+| Delete | **0.97ms** 🏆 | 1.00ms | 0.98ms | 1.10ms | 1.72ms |
+| Create Many (10 records) | 0.77ms | **0.72ms** 🏆 | 0.89ms | 1.00ms | 1.20ms |
+| Upsert Many (10 records) | **0.88ms** 🏆 | 0.90ms | 1.03ms | 1.06ms | 11.89ms |
+| Update Many (10 different values) | **0.70ms** 🏆 | 2.83ms | 2.75ms | 3.02ms | 5.31ms |
+| Nested relations (100→1000→10000) | 25.82ms | 24.65ms | **24.25ms** 🏆 | 80.56ms | 84.10ms |
+| Nested relations (composite key, 5 tenants) | 22.41ms | N/A | **16.26ms** 🏆 | 39.25ms | 219.00ms |
 <!--@embedoc:end-->
 
 *All write operations wrapped in transactions for fair comparison across all ORMs.*
 
 ### Analysis
 
-1. **litedbmodel** - **Fastest in write operations** 🏆
-   - **#1 in Filter/paginate, Create, Update (tie), Nested update, Nested upsert, Delete, Update Many**
-   - Update Many with different values: **3.6x - 7.0x faster** than other ORMs
+1. **litedbmodel** - **Fastest in read/write operations** 🏆
+   - **#1 in Filter/paginate, Nested find all, Find unique, Nested find unique, Nested create, Nested upsert (tie), Delete, Upsert Many, Update Many**
+   - Update Many with different values: **3.9x - 7.6x faster** than other ORMs
    - Excellent balance of read and write performance
 
 2. **Kysely** - **Strong simple query performance**
-   - **#1 in Find all (tie), Find first, Find unique, Nested find unique, Nested create, Upsert, Create Many, Upsert Many**
+   - **#1 in Find first, Create, Update, Create Many**
    - Minimal abstraction overhead
    - **Limitation:** Cannot batch load composite FK
 
 3. **Drizzle** - **Fastest in nested relations** 🏆
-   - **#1 in Find all (tie), Nested find all, Update (tie), Nested relations single key (22ms), Nested composite key (16ms)** using LATERAL JOIN
+   - **#1 in Find all, Nested update, Upsert, Nested upsert (tie), Nested relations single key (24ms), Nested composite key (16ms)** using LATERAL JOIN
    - Query API with relations provides excellent performance
 
 4. **TypeORM** - Variable performance
-   - **#1 in Update (tie), Nested find first** (JOIN-based approach)
-   - Decent composite key support (38ms)
+   - **#1 in Nested find first** (JOIN-based approach)
+   - Decent composite key support (39ms)
 
 5. **Prisma** - Convenience over speed
    - **Slowest in most operations** (1.5x - 14x slower)
-   - Composite key nested: 215ms (**14x slower** than Drizzle)
+   - Composite key nested: 219ms (**13x slower** than Drizzle)
    - Trade-off: Rich DX features (Prisma Studio, migrations, etc.)
 
 ---
@@ -89,33 +89,33 @@ Reference: [Kysely performance comparison article](https://izanami.dev/post/1e3f
 
 | ORM | Median | Ratio | Queries | Notes |
 |-----|--------|-------|---------|-------|
-| **Drizzle** 🏆 | **22.31ms** | **1.00x** | 1 | **LATERAL JOIN** |
-| Kysely | 23.74ms | 1.06x | 3 | Separate queries |
-| litedbmodel | 26.84ms | 1.20x | 3 | Separate queries + sync cache |
-| TypeORM | 75.25ms | 3.37x | 2 | JOIN-based |
-| Prisma | 83.91ms | 3.76x | 3 | Parameter explosion |
+| **Drizzle** 🏆 | **24.25ms** | **1.00x** | 1 | **LATERAL JOIN** |
+| Kysely | 24.65ms | 1.02x | 3 | Separate queries |
+| litedbmodel | 25.82ms | 1.06x | 3 | Separate queries + sync cache |
+| TypeORM | 80.56ms | 3.32x | 2 | JOIN-based |
+| Prisma | 84.10ms | 3.47x | 3 | Parameter explosion |
 
 ### Composite Key Relations (5 tenants × 100 users)
 
 | ORM | Median | Ratio | Queries | Notes |
 |-----|--------|-------|---------|-------|
-| **Drizzle** 🏆 | **15.75ms** | **1.00x** | 1 | **LATERAL JOIN with composite** |
-| litedbmodel | 23.38ms | 1.48x | 3 | unnest + JOIN |
-| TypeORM | 37.72ms | 2.39x | 2 | Multiple OR conditions |
-| Prisma | 214.51ms | 13.62x | 3 | Parameter explosion (2000+ params) |
+| **Drizzle** 🏆 | **16.26ms** | **1.00x** | 1 | **LATERAL JOIN with composite** |
+| litedbmodel | 22.41ms | 1.38x | 3 | unnest + JOIN |
+| TypeORM | 39.25ms | 2.41x | 2 | Multiple OR conditions |
+| Prisma | 219.00ms | 13.47x | 3 | Parameter explosion (2000+ params) |
 | Kysely | N/A | - | - | Cannot batch composite FK |
 
 ### Deep Nested Analysis
 
 **Single Key:**
-- Drizzle fastest with LATERAL JOIN (22ms)
-- Kysely close (24ms) with 3 separate queries
-- litedbmodel (27ms, 1.20x) with 3 separate queries
+- Drizzle fastest with LATERAL JOIN (24ms)
+- Kysely close (25ms) with 3 separate queries
+- litedbmodel (26ms, 1.06x) with 3 separate queries
 
 **Composite Key (multi-tenant):**
 - **Drizzle fastest (16ms)** with LATERAL JOIN query API
-- litedbmodel 1.48x (23ms) with `unnest + JOIN` approach
-- Prisma 14x slower with 2000+ parameters
+- litedbmodel 1.38x (22ms) with `unnest + JOIN` approach
+- Prisma 13x slower with 2000+ parameters
 - **Kysely cannot batch load composite FK** (would require manual tuple matching)
 
 > **Drizzle advantage:** LATERAL JOIN provides fastest nested relation loading for both single and composite keys when using the query API with relations.
@@ -538,11 +538,11 @@ WHERE (tenant_id, user_id) IN (($1,$2),($3,$4),...,($1999,$2000))
 
 | Scenario | Best Fit | Notes |
 |----------|----------|-------|
-| Write operations (transactions) | **litedbmodel** | Fastest in Create, Upsert, Delete, etc. |
-| Bulk Update (diff values) | **litedbmodel** | **3.8x - 7.3x faster** than others (single query) |
-| Nested find all | **litedbmodel** | Fastest at 3.59ms |
-| Nested single key (speed) | Drizzle | 1 query via LATERAL JOIN (22ms) |
-| Nested composite key (speed) | **litedbmodel** | **23ms** (7x faster than Drizzle, 9x faster than Prisma) |
+| Write operations (transactions) | **litedbmodel** | Fastest in Nested create, Delete, Upsert Many, etc. |
+| Bulk Update (diff values) | **litedbmodel** | **3.9x - 7.6x faster** than others (single query) |
+| Nested find all | **litedbmodel** | Fastest at 3.64ms |
+| Nested single key (speed) | Drizzle | 1 query via LATERAL JOIN (24ms) |
+| Nested composite key (speed) | Drizzle | 16ms via LATERAL JOIN |
 | Nested relation SQL quality | **litedbmodel** | Readable + debuggable; stable query patterns (PG) |
 | Log Analysis / Monitoring | **litedbmodel** | Consistent query patterns |
 | SQL Fingerprint Stability (PG) | **litedbmodel** | Most predictable in prepared-statement setups |
@@ -550,14 +550,14 @@ WHERE (tenant_id, user_id) IN (($1,$2),($3,$4),...,($1999,$2000))
 | Data Integrity | **litedbmodel** | Explicit transactions required for writes |
 
 **litedbmodel excels at:**
-- **Write operations** (Create, Nested create, Upsert, Delete - all fastest when using transactions)
-- **Bulk update with different values** (3.8x - 7.3x faster)
-- **Nested find all** (fastest at 3.40ms)
+- **Read operations** (Find unique, Nested find unique, Nested find all - all fastest)
+- **Write operations** (Nested create, Delete, Upsert Many, Update Many - fastest)
+- **Bulk update with different values** (3.9x - 7.6x faster)
 - **Consistent performance** across all operations
 - **Data integrity** via required transactions
 
-**vs Prisma:** litedbmodel is **1.6x - 14.4x faster** across operations  
-**vs Query Builders:** litedbmodel is **fastest for write operations** when all ORMs use transactions
+**vs Prisma:** litedbmodel is **1.5x - 13.5x faster** across operations  
+**vs Query Builders:** litedbmodel matches or beats Kysely/Drizzle in most operations
 
 > **litedbmodel provides best-in-class performance with safety guarantees:**
 > - Type-safe column symbols (IDE refactoring)
@@ -569,6 +569,6 @@ WHERE (tenant_id, user_id) IN (($1,$2),($3,$4),...,($1999,$2000))
 
 ---
 
-*Last updated: January 2026*  
+*Last updated: March 2026*  
 *Benchmark methodology: Based on [Prisma orm-benchmarks](https://github.com/prisma/orm-benchmarks)*
 

package/docs/COMPARISON.md

@@ -290,8 +290,8 @@ SKIP also works in `createMany` and `updateMany`:
 | Operation | SKIP Behavior |
 |-----------|---------------|
 | `create` / `update` | Column excluded from INSERT/UPDATE |
-| `createMany` | Column excluded → DB DEFAULT applied |
-| `updateMany` | Column excluded → existing value retained |
+| `createMany` | Column excluded → DB DEFAULT applied (see note below) |
+| `updateMany` | Column excluded → existing value retained (single query) |
 
 ```typescript
 // createMany - records grouped by SKIP pattern for efficient batch INSERT
@@ -307,6 +307,8 @@ await User.updateMany([
 ], { keyColumns: User.id });
 ```
 
+> **Note on `createMany` with SKIP:** `createMany` groups records by their SKIP pattern and issues a separate INSERT per group, because SQL does not allow mixing `DEFAULT` with array-based bulk insert (`UNNEST`). `updateMany` does not have this limitation — it handles SKIP in a single query using boolean flags. For best performance with `createMany`, prefer providing explicit values for all columns instead of using SKIP.
+
 ---
 
 ## 4. SQL-Friendly Design
@@ -1077,13 +1079,13 @@ For detailed benchmark results comparing litedbmodel with Prisma, Kysely, Drizzl
 
 | Operation Type | litedbmodel Performance |
 |----------------|------------------------|
-| Standard CRUD | **Fastest in 7/14 operations** (Find all, Filter/sort, Create, Upsert, Delete) |
-| Nested relations | Competitive (within 10% of fastest) |
-| Deep nested (10K) | 2.9x faster than Prisma |
+| Standard CRUD | **Fastest in 9/19 operations** (Filter/sort, Nested find all, Find unique, Nested find unique, Nested create, Delete, Upsert Many, Update Many, etc.) |
+| Nested relations | Competitive (within 6% of fastest) |
+| Deep nested (10K) | 3.3x faster than Prisma |
 | SQL quality | ⭐⭐⭐⭐⭐ (readable, fixed params on PG) |
 
-**vs Prisma:** litedbmodel is **1.6x - 5.9x faster** across all operations  
-**vs Query Builders:** litedbmodel is competitive (within 10%), with better DX
+**vs Prisma:** litedbmodel is **1.5x - 13.5x faster** across all operations  
+**vs Query Builders:** litedbmodel matches or beats Kysely/Drizzle in most operations
 
 ---
 

package/docs/api/README.md

@@ -1,4 +1,4 @@
-**litedbmodel v0.20.1**
+**litedbmodel v1.0.1**
 
 ***
 
@@ -407,8 +407,8 @@ class LoggingMiddleware extends Middleware {
   }
 }
 
-// Register middleware
-User.use(LoggingMiddleware);
+// Register middleware (applies to ALL models)
+DBModel.use(LoggingMiddleware);
 ```
 
 See: [Middleware](classes/Middleware.md)
@@ -463,13 +463,65 @@ await User.updateMany([
 ], { keyColumns: User.id });
 ```
 
-### Batch SQL Strategy by Database
+### SQL Generation Strategy (Complete Matrix)
+
+| DB | Operation | SKIP | SQL Strategy | SQL Example | Test |
+|----|-----------|------|--------------|-------------|------|
+| PostgreSQL | create | No | VALUES | `INSERT INTO t (name, arr, json) VALUES ($1, '{1,2}', '{"a":1}')` | ✅ |
+| PostgreSQL | create | Yes | VALUES (column excluded) | `INSERT INTO t (name, json) VALUES ($1, '{"a":1}')` - arr excluded | ✅ |
+| PostgreSQL | createMany | No | UNNEST | `INSERT INTO t SELECT v.name, (jsonb->arr), v.json::jsonb FROM UNNEST($1::text[], $2::text[], $3::text[]) AS v` | ✅ |
+| PostgreSQL | createMany | Yes | Group by SKIP pattern -> UNNEST per group | Same as above, SKIP columns excluded from INSERT -> DB DEFAULT | ✅ |
+| PostgreSQL | update | No | SET | `UPDATE t SET name=$1, arr='{1,2}', json='{"a":1}' WHERE id=$2` | ✅ |
+| PostgreSQL | update | Yes | SET (column excluded) | `UPDATE t SET name=$1, json='{"a":1}' WHERE id=$2` - arr excluded | ✅ |
+| PostgreSQL | updateMany | No | UNNEST | `UPDATE t SET arr=(jsonb->arr), json=v.json::jsonb FROM UNNEST(...) AS v WHERE t.id=v.id` | ✅ |
+| PostgreSQL | updateMany | Yes | UNNEST + skip_flag column | `SET arr=CASE WHEN v._skip_arr THEN t.arr ELSE (jsonb->arr) END` | ✅ |
+| MySQL | create | No | VALUES | `INSERT INTO t (name, status) VALUES (?, ?)` | ✅ |
+| MySQL | create | Yes | VALUES (column excluded) | `INSERT INTO t (name) VALUES (?)` - status excluded -> DB DEFAULT | ✅ |
+| MySQL | createMany | No | VALUES ROW | `INSERT INTO t (name, status) VALUES ROW(?,?), ROW(?,?)` | ✅ |
+| MySQL | createMany | Yes | Group by SKIP pattern -> VALUES per group | Same as above, SKIP columns excluded from INSERT -> DB DEFAULT | ✅ |
+| MySQL | update | No | SET | `UPDATE t SET name=?, status=? WHERE id=?` | ✅ |
+| MySQL | update | Yes | SET (column excluded) | `UPDATE t SET name=? WHERE id=?` - status excluded | ✅ |
+| MySQL | updateMany | No | JOIN VALUES ROW | `UPDATE t JOIN (VALUES ROW(?,?)) AS v ON t.id=v.id SET t.col=v.col` | ✅ |
+| MySQL | updateMany | Yes | JOIN VALUES + IF(skip_flag) | `SET t.status=IF(v._skip_status, t.status, v.status)` | ✅ |
+| SQLite | create | No | VALUES | `INSERT INTO t (name, status) VALUES (?, ?)` | ✅ |
+| SQLite | create | Yes | VALUES (column excluded) | `INSERT INTO t (name) VALUES (?)` - status excluded -> DB DEFAULT | ✅ |
+| SQLite | createMany | No | VALUES | `INSERT INTO t (name, status) VALUES (?,?), (?,?)` | ✅ |
+| SQLite | createMany | Yes | Group by SKIP pattern -> VALUES per group | Same as above, SKIP columns excluded from INSERT -> DB DEFAULT | ✅ |
+| SQLite | update | No | SET | `UPDATE t SET name=?, status=? WHERE id=?` | ✅ |
+| SQLite | update | Yes | SET (column excluded) | `UPDATE t SET name=? WHERE id=?` - status excluded | ✅ |
+| SQLite | updateMany | No | CASE WHEN | `UPDATE t SET status=CASE WHEN id=? THEN ? WHEN id=? THEN ? END WHERE id IN (?,?)` | ✅ |
+| SQLite | updateMany | Yes | CASE WHEN + column ref | `SET status=CASE WHEN id=1 THEN ? WHEN id=2 THEN t.status END` - SKIP uses column ref | ✅ |
+
+**Notes:**
+- PostgreSQL array types: In createMany/updateMany, `JSON.stringify()` -> `text[]` -> `jsonb_array_elements_text()` to deserialize
+- PostgreSQL JSON types: In createMany/updateMany, `JSON.stringify()` -> `text[]` -> `::jsonb` cast
+- MySQL/SQLite: Use `@column.json<T[]>()` for array-like data (stored as JSON text)
+- `(jsonb->arr)` = `COALESCE((SELECT array_agg(elem::int) FROM jsonb_array_elements_text(v.col::jsonb) AS elem), ARRAY[]::int[])`
+
+### Architecture: Driver-Specific SQL Building
+
+litedbmodel uses a `SqlBuilder` architecture to generate optimized SQL for each database:
+
+| Driver | Interface | INSERT Strategy | UPDATE Strategy |
+|--------|-----------|-----------------|-----------------|
+| PostgreSQL | `PostgresSqlBuilder` | VALUES for single, UNNEST for batch (2+) | UNNEST with skip flags |
+| MySQL | `MysqlSqlBuilder` | VALUES ROW | JOIN VALUES + IF |
+| SQLite | `SqliteSqlBuilder` | VALUES clause | CASE WHEN |
+
+Each driver also provides `DriverTypeCast` for serialization/deserialization:
 
-| Database | createMany | updateMany |
-|----------|------------|------------|
-| PostgreSQL | Grouped `UNNEST` INSERT | `UNNEST` + `CASE WHEN skip_flag` |
-| MySQL | Grouped `VALUES ROW` INSERT | `JOIN VALUES ROW` + `IF(skip_flag)` |
-| SQLite | Grouped `VALUES` INSERT | `CASE WHEN key=? THEN col ELSE ?` |
+```typescript
+interface DriverTypeCast {
+  serializeArray<T>(val: T[]): unknown;      // JS array -> DB format
+  deserializeArray<T>(val: unknown): T[];    // DB value -> JS array
+  serializeJson(val: unknown): unknown;      // JS object -> DB format
+  deserializeJson<T>(val: unknown): T;       // DB value -> JS object
+}
+```
+
+- **PostgreSQL**: Native array format `{1,2,3}`, native JSONB
+- **MySQL**: JSON column type with automatic serialization
+- **SQLite**: TEXT columns with JSON.stringify/JSON.parse
 
 See: [Conditions](classes/Conditions.md), [Values](classes/Values.md), [SKIP](variables/SKIP.md)
 

package/docs/api/classes/Conditions.md

@@ -1,4 +1,4 @@
-[**litedbmodel v0.20.1**](../README.md)
+[**litedbmodel v1.0.1**](../README.md)
 
 ***
 
@@ -6,7 +6,7 @@
 
 # Class: Conditions\<Model\>
 
-Defined in: Column.ts:627
+Defined in: Column.ts:628
 
 Type-safe builder for query conditions.
 Use array literals for static conditions, builder for dynamic construction.
@@ -47,7 +47,7 @@ if (query.active) where.add(User.is_active, true);
 new Conditions<Model>(initial?: Conds): Conditions<Model>;
 ```
 
-Defined in: Column.ts:633
+Defined in: Column.ts:634
 
 Create a Conditions builder, optionally with initial conditions.
 
@@ -71,7 +71,7 @@ Create a Conditions builder, optionally with initial conditions.
 get length(): number;
 ```
 
-Defined in: Column.ts:677
+Defined in: Column.ts:700
 
 Get the number of conditions.
 
@@ -87,7 +87,7 @@ Get the number of conditions.
 add<V>(column: Column<V, Model>, value: V | null | undefined): this;
 ```
 
-Defined in: Column.ts:642
+Defined in: Column.ts:643
 
 Add a type-safe column equality condition.
 
@@ -116,7 +116,7 @@ Add a type-safe column equality condition.
 addRaw(condition: string, value?: unknown): this;
 ```
 
-Defined in: Column.ts:650
+Defined in: Column.ts:651
 
 Add a raw condition with template literal (e.g., `${User.age} > ?`).
 
@@ -133,13 +133,80 @@ Add a raw condition with template literal (e.g., `${User.age} > ?`).
 
 ***
 
+### addSql()
+
+#### Call Signature
+
+```ts
+addSql<V>(fragment: SqlTypedFragment<V, Model>, value: V): this;
+```
+
+Defined in: Column.ts:670
+
+Add a type-safe sql-tagged condition.
+
+##### Type Parameters
+
+| Type Parameter |
+| ------ |
+| `V` |
+
+##### Parameters
+
+| Parameter | Type |
+| ------ | ------ |
+| `fragment` | [`SqlTypedFragment`](../interfaces/SqlTypedFragment.md)\<`V`, `Model`\> |
+| `value` | `V` |
+
+##### Returns
+
+`this`
+
+##### Example
+
+```typescript
+const where = new Conditions<User>();
+where.addSql(sql`${User.age} > ?`, 18);
+where.addSql(sql`${User.deleted_at} IS NULL`);
+```
+
+#### Call Signature
+
+```ts
+addSql(fragment: SqlTypedFragment<any, Model>): this;
+```
+
+Defined in: Column.ts:671
+
+Add a type-safe sql-tagged condition.
+
+##### Parameters
+
+| Parameter | Type |
+| ------ | ------ |
+| `fragment` | [`SqlTypedFragment`](../interfaces/SqlTypedFragment.md)\<`any`, `Model`\> |
+
+##### Returns
+
+`this`
+
+##### Example
+
+```typescript
+const where = new Conditions<User>();
+where.addSql(sql`${User.age} > ?`, 18);
+where.addSql(sql`${User.deleted_at} IS NULL`);
+```
+
+***
+
 ### or()
 
 ```ts
 or(...condGroups: readonly Conds[]): this;
 ```
 
-Defined in: Column.ts:662
+Defined in: Column.ts:685
 
 Add an OR condition group.
 
@@ -161,7 +228,7 @@ Add an OR condition group.
 build(): Conds;
 ```
 
-Defined in: Column.ts:670
+Defined in: Column.ts:693
 
 Build the final array for use with find/count/delete.
 

package/docs/api/classes/DBHandler.md

@@ -1,4 +1,4 @@
-[**litedbmodel v0.20.1**](../README.md)
+[**litedbmodel v1.0.1**](../README.md)
 
 ***
 
@@ -48,7 +48,7 @@ Defined in: DBHandler.ts:180
 ### getDriverType()
 
 ```ts
-getDriverType(): "postgres" | "sqlite" | "mysql";
+getDriverType(): "postgres" | "mysql" | "sqlite";
 ```
 
 Defined in: DBHandler.ts:198
@@ -57,7 +57,7 @@ Get the driver type
 
 #### Returns
 
-`"postgres"` \| `"sqlite"` \| `"mysql"`
+`"postgres"` \| `"mysql"` \| `"sqlite"`
 
 ***