directus / directus/rstore

Add MSSQL dialect support to @rstore/nuxt-drizzle

Open
#61 1 comment 0 reactions 0 assignees View on GitHub
Dominant language
TypeScript
Stars
449
Forks
21
Avg merge
6d 22h
Merged PRs (30d)
2

Description

### Clear and concise description of the problem

Loading the module with an MSSQL-dialect `drizzle.config.ts` fails at startup. The root cause is a hard-coded dialect switch in `module.mjs` that has no `mssql` case. Every `mssqlTable` schema entry falls through with `config === undefined`, and the build then errors in a downstream `instanceof` check.

Observed on:

- `@rstore/nuxt-drizzle@0.8.4`
- `@rstore/nuxt@0.8.4`
- `drizzle-orm@1.0.0-beta.22`
- `drizzle-kit@1.0.0-beta.22`
- Nuxt 3.21

Representative `drizzle.config.ts`:

```ts
export default defineConfig({
out: './drizzle',
schema: './server/db/schema.ts',
dialect: 'mssql',
dbCredentials: { url: process.env.NUXT_DATABASE_URL ?? '' },
})
```

Dev server output:

```
Pre-transform error: Failed to resolve import "#build/$rstore-drizzle-collections.js"
ERROR [unhandledRejection] Could not load virtual:$rstore-drizzle-server-utils.js
TypeError: Right-hand side of 'instanceof' is not an object
at is (drizzle-orm/entity.js:6:12)
at nuxt-drizzle/dist/module.mjs:128:39
```

The missing dialect case and the `Relations` import (see Additional context) are currently the only things standing between rstore and a fairly common enterprise stack: Nuxt + Drizzle + MSSQL (via `msnodesqlv8` / `mssql`).

### Suggested solution

1. Add an `mssql` case to the dialect switch

In `packages/nuxt-drizzle/src/module.ts` (shipped as `module.mjs`), the switch around line 99 that maps each `drizzleConfig.dialect` to its `getTableConfig` import:

```ts
switch (drizzleConfig.dialect) {
case 'postgresql': {
const { getTableConfig } = await import('drizzle-orm/pg-core')
config = getTableConfig(schemaItem)
break
}
case 'mysql': {
const { getTableConfig: getMySqlTableConfig } = await import('drizzle-orm/mysql-core')
config = getMySqlTableConfig(schemaItem)
break
}
case 'sqlite': {
const { getTableConfig: getSqliteTableConfig } = await import('drizzle-orm/sqlite-core')
config = getSqliteTableConfig(schemaItem)
break
}
case 'singlestore': {
const { getTableConfig: getSingleStoreTableConfig } = await import('drizzle-orm/singlestore-core')
config = getSingleStoreTableConfig(schemaItem)
break
}
// add:
case 'mssql': {
const { getTableConfig: getMsSqlTableConfig } = await import('drizzle-orm/mssql-core')
config = getMsSqlTableConfig(schemaItem)
break
}
}
```

`drizzle-orm/mssql-core` already exports `getTableConfig` with the same `{ columns, primaryKeys, ... }` shape the rest of the module consumes — verified against `drizzle-orm@1.0.0-beta.22`. The existing primary-key resolution logic (`config.primaryKeys?.[0]?.columns` with a `config.columns.filter(c => c.primary)` fallback) should work without modification for `mssqlTable`.

2. Recognize MSSQL tables in `isTable(...)`

`isTable` from `drizzle-orm` already returns true for `mssqlTable`-produced instances, so no change needed there — just flagging so reviewers can confirm.

3. Default driver path

The `drizzleImport` default (`~~/server/utils/drizzle`) is dialect-agnostic; users plug in their own instance (`drizzle({ connection, schema })` from `drizzle-orm/node-mssql`). No change needed.

4. Tests / fixtures

Add an MSSQL fixture parallel to the existing Postgres/MySQL/SQLite ones — a minimal `mssqlTable` schema and a test asserting that collections are generated for it and a basic `findMany` round-trips through the generated REST endpoint.

### Alternative

### Additional context

While diagnosing the MSSQL blocker, I hit a second crash that's independent of dialect:

```
TypeError: Right-hand side of 'instanceof' is not an object
at is (drizzle-orm/entity.js:6:12)
at nuxt-drizzle/dist/module.mjs:128:39 // `is(schemaItem, Relations)`
```

`module.mjs` imports `Relations` from the `drizzle-orm` root, but in `drizzle-orm@1.0.0-beta.22` that named export no longer exists — the API moved to `Relation` (singular), `defineRelations`, and `createRelationsHelper` (verified in `drizzle-orm/index.d.ts`).

This means `@rstore/nuxt-drizzle@0.8.4` is additionally incompatible with the `1.0` line of `drizzle-orm`, even on dialects that *are* in the switch. For the MSSQL support work it's worth resolving together, since most MSSQL users will be on `drizzle-orm ≥ 1.0` (where MSSQL first landed).

Suggested fix: migrate the relations-detection path from the legacy `Relations` class to `defineRelations` / the new `buildRelations` helpers.

### Validations

- [x] Follow our [Code of Conduct](https://github.com/Akryum/rstore/blob/main/CODE_OF_CONDUCT.md)
- [x] Read the [Contributing Guidelines](https://github.com/Akryum/rstore/blob/main/CONTRIBUTING.md).
- [x] Read the [docs](https://rstore.starpad.dev/guide/).
- [x] Check that there isn't [already an issue](https://github.com/Akryum/rstore/issues) that requests the same feature to avoid creating a duplicate.

Contributor guide

Open the contributing guide

Assessment

This issue has not been assessed yet.

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.