Kairu
Kairu
Explore posts from servers
DTDrizzle Team
Created by Kairu on 10/25/2024 in #help
Nextjs pages router: You may need an appropriate loader to handle this file type
next: 14.2.15 drizzle: 0.35.3 libsql/client: 0.14.0 To get PDF rendering working, it was suggested to me that I move a route from app router to pages router. Everything checks out on the type level, but I'm getting this error in runtime:
⨯ ../../packages/schema/src/builder/schema.ts
│ Module parse failed: Unexpected token (20:59)
│ You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file. See https://webpack.js.org/concepts#loaders
│ | createdBy: text("created_by"),
│ | organizationId: text("organization_id"),
│ > status: text("status").notNull().$type<TemplateStatus>(),
│ | title: text("title").notNull(),
│ | scoringMethod: text("scoring_method").notNull().$type<ScoringMethod>(),

│ Import trace for requested module:
│ ../../packages/schema/src/builder/schema.ts
│ ../../packages/schema/src/system/index.ts
│ ./src/pages/api/reports/[organization]/[workspace]/[assessment]/[reportType].tsx
⨯ ../../packages/schema/src/builder/schema.ts
│ Module parse failed: Unexpected token (20:59)
│ You may need an appropriate loader to handle this file type, currently no loaders are configured to process this file. See https://webpack.js.org/concepts#loaders
│ | createdBy: text("created_by"),
│ | organizationId: text("organization_id"),
│ > status: text("status").notNull().$type<TemplateStatus>(),
│ | title: text("title").notNull(),
│ | scoringMethod: text("scoring_method").notNull().$type<ScoringMethod>(),

│ Import trace for requested module:
│ ../../packages/schema/src/builder/schema.ts
│ ../../packages/schema/src/system/index.ts
│ ./src/pages/api/reports/[organization]/[workspace]/[assessment]/[reportType].tsx
I saw this issue: https://github.com/drizzle-team/drizzle-orm/issues/3155 Switched all my Turso stuff over to using /web but it still happens. Just tried making a minimal repro but it seems to work fine. I'm not familiar with pages router at all, as I started using React/Next with app router. All I know is that this is a webpack thing, I just have no idea why it would error on a column with a type set on it..
3 replies
RRailway
Created by Kairu on 9/21/2024 in #✋|help
Making postgres instance publicly available
I have an umami deployment and I'm looking to make the pg instance publicly accessible so I can back it up. I generated a domain (and redeployed) but it's inaccessible. Judging by the data tab in the UI, I need to add these extra variables? Just unsure if adding these would interfere with the actual deployment
5 replies
DTDrizzle Team
Created by Kairu on 3/7/2024 in #help
Executing database migrations on Vercel
now planetscale is removing their free tier, i'm looking to move, which probably means i gotta use migrations now i'm using next so my build command is just next build my assumption is that i would just change this to next build && tsx ./migrate.ts is this the go-to for running migrations on serverless? is it possible to run migrations inside a transaction so if anything fails, the schema doesn't remain in a broken state?
2 replies
DTDrizzle Team
Created by Kairu on 1/16/2024 in #help
Drizzle and multi-tenancy
I've been given a project that requires a degree of multi-tenancy. The system database will contain users, organizations, sub-organizations and all the links between these entities, then all tenant-specific entities would reside in the separate database. The client is asking for a separate database per tenant for two reasons: 1. to prevent data leakage between tenants 2. to allow tenants to pick their region To me, 1 isn't much of an issue as it can be alleviated with testing queries and rigorous testing in a staging environment. 2 is a little more complicated, and I'm asking for further clarification on if this is a legal thing or not. Personally, I'm mostly concerned about the prospect of needing to run migrations on dozens of identical but separate databases. While it looks like it can be done rather easily with Drizzle by just looping over the tenants and building a new instance of the client, I've done multi-database multi-tenancy before and it was a bit of a pain, not something I would like to repeat. Right now I'm considering using Turso as it has a high limit on database count and databases can be created programmatically via their API. On the other hand, just using a single MySQL/Postgres instance, switching databases via the USE statement, and keeping everything within SQL sounds easier than having another layer via the Turso API. I'm also unsure how Turso would handle constant re-creations of the Drizzle client every time separate tenants require a connection, instead of maintaining the same one connection. Any recommendations on approach or if I'm missing anything I should be considering?
8 replies
DTDrizzle Team
Created by Kairu on 11/18/2023 in #help
Vercel error when using both PlanetScale and Postgres in the same Next app
I'm using two separate databases for my app. The PlanetScale one is the "main" database, and the Postgres is a self-hosted database. I have separate Drizzle instances and schemas for both. PlanetScale:
// @/lib/server/db/index.ts
import { drizzle } from "drizzle-orm/planetscale-serverless";
import { connect } from "@planetscale/database";
import { env } from "@/env.mjs";
import * as schema from "./schema";

const connection = connect({
host: env.DATABASE_HOST,
username: env.DATABASE_USERNAME,
password: env.DATABASE_PASSWORD,
});

export const db = drizzle(connection, { schema });
// @/lib/server/db/index.ts
import { drizzle } from "drizzle-orm/planetscale-serverless";
import { connect } from "@planetscale/database";
import { env } from "@/env.mjs";
import * as schema from "./schema";

const connection = connect({
host: env.DATABASE_HOST,
username: env.DATABASE_USERNAME,
password: env.DATABASE_PASSWORD,
});

export const db = drizzle(connection, { schema });
Postgres:
// @/lib/server/db/indexer/index.ts
import { drizzle } from "drizzle-orm/postgres-js";
import postgres from "postgres";
import * as schema from "./schema";
import { env } from "@/env.mjs";

const client = postgres({
host: env.INDEXER_DB_HOST,
username: env.INDEXER_DB_USERNAME,
password: env.INDEXER_DB_PASSWORD,
port: env.INDEXER_DB_PORT,
database: env.INDEXER_DB_NAME,
});

export const indexer = drizzle(client, { schema });
// @/lib/server/db/indexer/index.ts
import { drizzle } from "drizzle-orm/postgres-js";
import postgres from "postgres";
import * as schema from "./schema";
import { env } from "@/env.mjs";

const client = postgres({
host: env.INDEXER_DB_HOST,
username: env.INDEXER_DB_USERNAME,
password: env.INDEXER_DB_PASSWORD,
port: env.INDEXER_DB_PORT,
database: env.INDEXER_DB_NAME,
});

export const indexer = drizzle(client, { schema });
Other than needing to switch pages that use the pg connection over to nodejs instead of edge, this works well locally. I've just tried to deploy to Vercel and I'm getting this error:
./src/lib/server/db/indexer/schema.ts + 55 modules
Cannot get final name for export 'PgColumn' of ./node_modules/.pnpm/[email protected]_@[email protected][email protected]/node_modules/drizzle-orm/pg-core/columns/index.js
./src/lib/server/db/indexer/schema.ts + 55 modules
Cannot get final name for export 'PgColumn' of ./node_modules/.pnpm/[email protected]_@[email protected][email protected]/node_modules/drizzle-orm/pg-core/columns/index.js
I'm thinking I should just load up the pg HTTP proxy on my server and use that but I'd rather not add another layer of complexity here.
3 replies
DTDrizzle Team
Created by Kairu on 5/20/2023 in #help
Many-to-many relational query issues
schema, relations, statements: https://gist.github.com/kylewardnz/37104f989807e96555ea856294a2b670 1) executing the fetchArtistWithContent statement returns only the pivot table data on the members relation. This does make sense since it's actually a relation to that table, but logically I'm wanting the data from the members table. This can be done by changing the with statement to:
with: {
albums: true,
members: {
member: true,
},
},
with: {
albums: true,
members: {
member: true,
},
},
but now it's all nested under another key. Not the end of the world, but it'd be nice if we were able to specify a relation on that pivot to pull from, something like:
export const artistRelations = relations(artists, ({ one, many }) => ({
members: many(artistsToMembers, membersTable),
}))
export const artistRelations = relations(artists, ({ one, many }) => ({
members: many(artistsToMembers, membersTable),
}))
Passing in { relationName: 'member' } as a second argument to many() (and vice versa on the inverse relation) results in There is not enough information to infer relation "artists.members" so I'm guessing this isn't the use case 2) executing the fetchAlbumWithContent statement results in a couple things: - the above issue on the versions.photocardSets key - this issue on all relations: https://github.com/drizzle-team/drizzle-orm/issues/599 then, I was wondering if there was a way within one query, to then append a new key called albumVersionIds onto each record under the photocardSets key, which is just a list of albumVersion ids that it's related to. This would be handy for being able to pass the record directly into an update form. Something like this I suppose? Not sure what would replace ??? and I would guess this causes the n+1 problem too
export const fetchAlbumWithContent = db.query.albums
.findFirst({
where: (albums, { eq }) => eq(albums.id, placeholder("id")),
with: {
...
photocardSets: {
extras: {
albumVersionIds: sql<number[]>`select album_version_id from photocard_set_to_album_version where photocard_set_id = ???`.as('album_version_ids')
}
},
},
})
.prepare()
export const fetchAlbumWithContent = db.query.albums
.findFirst({
where: (albums, { eq }) => eq(albums.id, placeholder("id")),
with: {
...
photocardSets: {
extras: {
albumVersionIds: sql<number[]>`select album_version_id from photocard_set_to_album_version where photocard_set_id = ???`.as('album_version_ids')
}
},
},
})
.prepare()
(figured I'd make another thread since this is unrelated to kit)
3 replies
DTDrizzle Team
Created by Kairu on 5/20/2023 in #help
drizzle-kit: push wants to change column type that hasn't changed
just updated my dependencies:
dependencies:
- drizzle-orm 0.25.4
+ drizzle-orm 0.26.0
devDependencies:
- drizzle-kit 0.17.6-76e73f3
+ drizzle-kit 0.18.0
dependencies:
- drizzle-orm 0.25.4
+ drizzle-orm 0.26.0
devDependencies:
- drizzle-kit 0.17.6-76e73f3
+ drizzle-kit 0.18.0
here's my truncated schema
export const artists = mysqlTable("artists", {
id: serial("id").primaryKey(),
name: varchar("name", { length: 50 }).notNull(),
isGroup: boolean("is_group").notNull().default(true),
})
export const artists = mysqlTable("artists", {
id: serial("id").primaryKey(),
name: varchar("name", { length: 50 }).notNull(),
isGroup: boolean("is_group").notNull().default(true),
})
push:mysql results in: You're about to change is_group column type from alter_table_alter_column_set_type to boolean with 1 items is_group has always been a boolean, it hasn't been touched in a while, let alone just now between dependency changes. and unless it's some kind of internal thing, alter_table_alter_column_set_type doesn't sound like a valid column type. downgrading kit back down to 0.17.6-76e73f3 works (i have no changes right now)
4 replies