Out of curiosity, with Durable Objects having a KV API, and now an SQL API, what would you get out o

Llambrospetrou Out of curiosity, with Durable Objects having a KV API, and now an SQL API, what...

�

😈 Donkey 💫•10/2/24, 10:25 AM

After doing quick research, SQL api is promising

�

😈 Donkey 💫•10/2/24, 10:25 AM

I'm thinking about Document DB because of native ORM, UI dashboard (expect), manually set index,..

D

dangoldin•10/2/24, 2:51 PM

probably a dumb question but is there a way for me to query a D1 database that's running locally/dev mode? i set up a standard sqlite driver in datagrip with the path in .wrangler and the queries work and tables have the right structure but no data is returned. the app is reading the data just fine. i wonder if it's due to the wal/shm files not being compacted into the main sqlite file?

Ddangoldin probably a dumb question but is there a way for me to query a D1 database that's...

L

lambrospetrouOP•10/2/24, 3:58 PM

You can get to the raw sqlite files under

.wrangler

.wrangler

.wrangler

.wrangler, but don't mess them up outside of your worker code to avoid unexpected behavior

If things break, you can clean up and reset by deleting those files.

Llambrospetrou You can get to the raw sqlite files under `.wrangler`, but don't mess them up ou...

D

dangoldin•10/2/24, 4:07 PM

well that's what i'm trying to do but they show up as empty when i query them. for example:

D

dangoldin•10/2/24, 4:08 PM

in this case datagrip is configured to point to

199187a5c9948d6a9eaef3ee19490fb5eec30c2012c4b4101aaeb362f07f1d3e.sqlite

199187a5c9948d6a9eaef3ee19490fb5eec30c2012c4b4101aaeb362f07f1d3e.sqlite

199187a5c9948d6a9eaef3ee19490fb5eec30c2012c4b4101aaeb362f07f1d3e.sqlite

199187a5c9948d6a9eaef3ee19490fb5eec30c2012c4b4101aaeb362f07f1d3e.sqlite

D

dangoldin•10/2/24, 4:09 PM

i think i need to get wrangler/miniflare to force it to flush and then i'll be able to access via non-cloudflare tooling

C

Cyb3r-Jak3•10/2/24, 4:10 PM

You should be able to do

wrangler d1 execute —local <query>

wrangler d1 execute —local <query>

wrangler d1 execute —local <query>

wrangler d1 execute —local <query> https://developers.cloudflare.com/workers/wrangler/commands/#execute

Cloudflare Docs

Commands | Cloudflare Workers docs

Create, develop, and deploy your Cloudflare Workers with Wrangler commands.

D

dangoldin•10/2/24, 4:12 PM

cool - will explore more!

D

dangoldin•10/2/24, 4:13 PM

weird. the command also returns nothing but if i query it within the app (remix), it works perfectly

D

dangoldin•10/2/24, 4:13 PM

must be pointing to a different sqlite ha

D

dangoldin•10/2/24, 4:14 PM

ah that's what it is i think - the app with prisma is writing to a different sqlite file. urg i'm dumb

M

mallets•10/3/24, 7:35 AM

Now I don't what's easier for CF to implement, but I wouldn't mind the 10GB/database limit if we can have 1 DB per user. These DBs could end up with 100KB max or a couple GB.
But that runs into the 50K limit. Will CF increase this limit easily upon request or should I just fragment tables over multiple DBs?
Feels like managing a "managed" DB service.

Original message was deleted

M

mallets•10/3/24, 8:23 AM

Good to know.
Unrelated, but I am confused by the pricing per read request. An old 2023 blog post mentions read units (4KB), while the current pricing is simply per row read.
Hope that means reading a "heavy" 512KB blob row still counts as a single read now?

M

mallets•10/3/24, 8:30 AM

Also a bit odd that it's "cheaper" to store small files on D1, if they need to be accessed a lot. R2 is 360x more costly per read but 50x cheaper GB/month.

M

mallets•10/3/24, 8:34 AM

Thinking of storing small emails completely on D1 and a path to R2 for the bigger ones.

Mmallets Also a bit odd that it's "cheaper" to store small files on D1, if they need to b...

B

boop•10/3/24, 10:42 AM

Don't forget about the cache in front of R2. You wont be billed a ~~read request~~ Class B if it hits the cache

Z

Zane Shannon•10/4/24, 2:42 AM

hey crew, i'm using d1 with prisma and getting abysmal performance on workers but totally reasonable on localhost. i don't think it's the location bit because i'm in san francisco and the database is located in WNAM. any hints about where to look?

ZZane Shannon hey crew, i'm using d1 with prisma and getting abysmal performance on workers bu...

M

mallets•10/4/24, 9:36 AM

If this is about query latency, there is a good chance the worker was invoked on the other side of the globe. Something about routing priorities based on account plan. A CF node exists in the same city as me but connections to any free plan resource is 8000kms away.

https://cloudflare-test.judge.sh/

M

mallets•10/4/24, 9:46 AM

Check the http response headers, the airport code is the location of the serving worker.

MMax (@rozenmd)aight i'll cut a PR

D

divby0•10/4/24, 10:03 AM

what happened to that pr? Asking because newest wrangler (3.79) still makes this mistake and doesn't apply in the right order

If there's any help needed, I'd be happy to try writing the PR if you didn't have time yet

K

Kyle•10/4/24, 2:56 PM

Hi, is this blog post still relevant? It says the D1 API is in beta testing, but this was written 2 years ago. So, would the procedures call be available? Couldn't get it work the other day in typescript or javascript.

https://blog.cloudflare.com/whats-new-with-d1/

The Cloudflare Blog

D1: our quest to simplify databases

Get an inside look on the D1 experience today, what the team is currently working on and what’s coming up!

KKyle Hi, is this blog post still relevant? It says the D1 API is in beta testing, but...

L

Larry•10/4/24, 6:32 PM

I also read that again recently and was surprised by the stored procedure reference. That was an earlier discussion of the possibilities but instead of getting implemented inside of D1, my best guess is that this is now implemented by using DOs with the

sql.exec()

sql.exec()

sql.exec()

sql.exec() interface.

A

Acе•10/4/24, 9:16 PM

Seems like a lot of things in that blog post are false…

A

Acе•10/4/24, 9:16 PM

"today, we don't try to run a copy in every location worldwide, but dynamically manage the number and location of read-only replicas based on how many queries your database is getting"

D

dev•10/5/24, 4:15 AM

hey folks, what's the typical workflow for teams working with D1? I was able to get pages+d1 working great with preview environments etc, but a few things are falling short... every time I create a PR, I'm using

wrangler pages deploy --branch $BITBUCKET_BRANCH

wrangler pages deploy --branch $BITBUCKET_BRANCH

wrangler pages deploy --branch $BITBUCKET_BRANCH

wrangler pages deploy --branch $BITBUCKET_BRANCH to deploy a preview environment and

wrangler d1 migrations apply --remote --env preview

wrangler d1 migrations apply --remote --env preview

wrangler d1 migrations apply --remote --env preview

wrangler d1 migrations apply --remote --env preview to apply the migrations to the preview db. that's awesome and pretty easy. however, all the preview envs share the same database, so how should I handle two PRs making db changes? or another very common use case: I start my PR with a single db change, but after PR reviews, I want to add/remove changes from the migration.
kinda the same issue as local development: if I checkout a branch to test it locally, then I can't really reset my local d1 instance to how it was before. I have to

rm -rf ./.wrangler/state/v3/d1

rm -rf ./.wrangler/state/v3/d1

rm -rf ./.wrangler/state/v3/d1

rm -rf ./.wrangler/state/v3/d1 and re-apply the migrations from

main

main

.
I'm just curious to understand how other teams with multiple people are working with D1 considering these factors. Thanks!

Ddev hey folks, what's the typical workflow for teams working with D1? I was able to ...

A

Ashley•10/5/24, 9:09 AM

I would personally spin up a whole new environment per branch like you’re doing but then as it’s a serverless platform, it’s pretty easy to have a script that creates new resources, do a bit of Bash to extract the bindings from the create commands, and then put in wrangler.toml and then do your deploy. You’d probably want some clean up to run on merge to delete the resources too (if you’re using GH Actions or something)

P

preetramsha•10/5/24, 12:24 PM

PLEASE HELP!

I am not able to delete (drop) a table on production.

P

preetramsha•10/5/24, 12:27 PM

here it is

P

preetramsha•10/5/24, 12:28 PM

I wanted to remove some foreign key constrains that's why I was making the new table

P

preetramsha•10/5/24, 12:28 PM

what to do now?

Original message was deleted

P

preetramsha•10/5/24, 12:28 PM

hello you there?

AAshley I would personally spin up a whole new environment per branch like you’re doing ...

D

dev•10/5/24, 3:38 PM

Yeah.. I’m thinking this is the best approach as well.. however, that only fixes the preview part. Local dev is still not ideal. It means I’ll probably be resetting the local database all the time

Ddev Yeah.. I’m thinking this is the best approach as well.. however, that only fixe...

J

James•10/5/24, 4:00 PM

you could script local dev to use a different wrangler state d1 folder per branch

Ddev Yeah.. I’m thinking this is the best approach as well.. however, that only fixe...

A

Ashley•10/5/24, 4:19 PM

I tend to do that anyway, makes it nice and clean per branch with no contamination possible - and if you need state in the DB for config etc. just put it in a migration so it's always ready to go

AAshley I tend to do that anyway, makes it nice and clean per branch with no contaminati...

D

dev•10/5/24, 4:54 PM

any scripts you can share so I can reuse some of it?

JJames you could script local dev to use a different wrangler state d1 folder per branc...

D

dev•10/5/24, 4:55 PM

interesting.. so every branch gets its own local wrangler state locally as well.. I kinda like this. have you implemented this yourself?

Ddev interesting.. so every branch gets its own local wrangler state locally as well....

J

James•10/5/24, 5:03 PM

yeah i run this in through my package json, caveat folder path is my local ref

const { execSync } = require('child_process');
const { spawnSync } = require('child_process');
const fs = require('fs');
const path = require('path');

// Get current git branch
const branch = execSync('git rev-parse --abbrev-ref HEAD').toString().trim();

// Sanitize branch name to be used as a folder name
const sanitizedBranch = branch.replace(/[^a-zA-Z0-9-_]/g, '_');

// Define the persist folder path
const persistFolder = path.resolve(`../whateverFolder/.wrangler/state/${sanitizedBranch}/`);

// Ensure the persist folder exists
if (!fs.existsSync(persistFolder)) {
  fs.mkdirSync(persistFolder, { recursive: true });
  console.log(`Created persist folder: ${persistFolder}`);
} else {
  console.log(`Persist folder already exists: ${persistFolder}`);
}

console.log(`Persisting data to: ${persistFolder}`);

// Run wrangler dev with the dynamic persist folder
const result = spawnSync('wrangler', [
  'dev',
  `--persist-to=${persistFolder}`
], { stdio: 'inherit' });

if (result.error) {
  console.error('Error running wrangler:', result.error);
  process.exit(1);
}

const { execSync } = require('child_process');
const { spawnSync } = require('child_process');
const fs = require('fs');
const path = require('path');

// Get current git branch
const branch = execSync('git rev-parse --abbrev-ref HEAD').toString().trim();

// Sanitize branch name to be used as a folder name
const sanitizedBranch = branch.replace(/[^a-zA-Z0-9-_]/g, '_');

// Define the persist folder path
const persistFolder = path.resolve(`../whateverFolder/.wrangler/state/${sanitizedBranch}/`);

// Ensure the persist folder exists
if (!fs.existsSync(persistFolder)) {
  fs.mkdirSync(persistFolder, { recursive: true });
  console.log(`Created persist folder: ${persistFolder}`);
} else {
  console.log(`Persist folder already exists: ${persistFolder}`);
}

console.log(`Persisting data to: ${persistFolder}`);

// Run wrangler dev with the dynamic persist folder
const result = spawnSync('wrangler', [
  'dev',
  `--persist-to=${persistFolder}`
], { stdio: 'inherit' });

if (result.error) {
  console.error('Error running wrangler:', result.error);
  process.exit(1);
}

const { execSync } = require('child_process');
const { spawnSync } = require('child_process');
const fs = require('fs');
const path = require('path');

// Get current git branch
const branch = execSync('git rev-parse --abbrev-ref HEAD').toString().trim();

// Sanitize branch name to be used as a folder name
const sanitizedBranch = branch.replace(/[^a-zA-Z0-9-_]/g, '_');

// Define the persist folder path
const persistFolder = path.resolve(`../whateverFolder/.wrangler/state/${sanitizedBranch}/`);

// Ensure the persist folder exists
if (!fs.existsSync(persistFolder)) {
  fs.mkdirSync(persistFolder, { recursive: true });
  console.log(`Created persist folder: ${persistFolder}`);
} else {
  console.log(`Persist folder already exists: ${persistFolder}`);
}

console.log(`Persisting data to: ${persistFolder}`);

// Run wrangler dev with the dynamic persist folder
const result = spawnSync('wrangler', [
  'dev',
  `--persist-to=${persistFolder}`
], { stdio: 'inherit' });

if (result.error) {
  console.error('Error running wrangler:', result.error);
  process.exit(1);
}

const { execSync } = require('child_process');
const { spawnSync } = require('child_process');
const fs = require('fs');
const path = require('path');

// Get current git branch
const branch = execSync('git rev-parse --abbrev-ref HEAD').toString().trim();

// Sanitize branch name to be used as a folder name
const sanitizedBranch = branch.replace(/[^a-zA-Z0-9-_]/g, '_');

// Define the persist folder path
const persistFolder = path.resolve(`../whateverFolder/.wrangler/state/${sanitizedBranch}/`);

// Ensure the persist folder exists
if (!fs.existsSync(persistFolder)) {
  fs.mkdirSync(persistFolder, { recursive: true });
  console.log(`Created persist folder: ${persistFolder}`);
} else {
  console.log(`Persist folder already exists: ${persistFolder}`);
}

console.log(`Persisting data to: ${persistFolder}`);

// Run wrangler dev with the dynamic persist folder
const result = spawnSync('wrangler', [
  'dev',
  `--persist-to=${persistFolder}`
], { stdio: 'inherit' });

if (result.error) {
  console.error('Error running wrangler:', result.error);
  process.exit(1);
}

JJames yeah i run this in through my package json, caveat folder path is my local ref ...

D

dev•10/5/24, 6:49 PM

Thanks. I appreciate it. I have a script to sync prisma migrations with d1 as well. I’ll share when I’m back at my pc.

D

dev•10/5/24, 6:49 PM

I feel most of these DX issues are solvable with scripts, but it’s a bummer that it’s not baked in

M

matt•10/6/24, 2:16 AM

lets say you have a json column of str -> str, with unknown keys can you create an index per each key?

K

Kyzer•10/6/24, 11:09 PM

Hey, is anyone able to look at these database (9ba874c7-30f8-436c-a357-2b674e0a2e79) metrics please?
Apparently I've gone through 2.16B Rows read this month on a database with a total of about ~20k rows.
I've checked the insights and this is the main culprit, but running this command returns about 6k rows (total of ~12k reads as the join is pretty much a 1 to 1).

npx wrangler d1 insights DB --env="preview" --timePeriod="7d" --sort-by="reads" --json

npx wrangler d1 insights DB --env="preview" --timePeriod="7d" --sort-by="reads" --json

npx wrangler d1 insights DB --env="preview" --timePeriod="7d" --sort-by="reads" --json

npx wrangler d1 insights DB --env="preview" --timePeriod="7d" --sort-by="reads" --json

{
    "query": "select \"entry\".\"uuid\", \"entry\".\"type\", \"entry\".\"description\", \"entry\".\"userId\", \"entry\".\"createdOn\", \"entry\".\"updatedOn\", \"engineeringEntry\".\"planType\", \"engineeringEntry\".\"location\", \"engineeringEntry\".\"suburb\", \"engineeringEntry\".\"planStatus\", \"engineeringEntry\".\"designer\", \"engineeringEntry\".\"date\", \"engineeringEntry\".\"subdNumber\", \"engineeringEntry\".\"planRegister\" from \"entry\" left join \"engineeringEntry\" on \"entry\".\"uuid\" = \"engineeringEntry\".\"entryUuid\" where \"entry\".\"type\" = ?",
    "avgRowsRead": 37357286,
    "totalRowsRead": 2316151764,
    "avgRowsWritten": 0,
    "totalRowsWritten": 0,
    "avgDurationMs": 4197.161798387097,
    "totalDurationMs": 260224.0315,
    "numberOfTimesRun": 62,
    "queryEfficiency": 0.00016227088873640338
  }

{
    "query": "select \"entry\".\"uuid\", \"entry\".\"type\", \"entry\".\"description\", \"entry\".\"userId\", \"entry\".\"createdOn\", \"entry\".\"updatedOn\", \"engineeringEntry\".\"planType\", \"engineeringEntry\".\"location\", \"engineeringEntry\".\"suburb\", \"engineeringEntry\".\"planStatus\", \"engineeringEntry\".\"designer\", \"engineeringEntry\".\"date\", \"engineeringEntry\".\"subdNumber\", \"engineeringEntry\".\"planRegister\" from \"entry\" left join \"engineeringEntry\" on \"entry\".\"uuid\" = \"engineeringEntry\".\"entryUuid\" where \"entry\".\"type\" = ?",
    "avgRowsRead": 37357286,
    "totalRowsRead": 2316151764,
    "avgRowsWritten": 0,
    "totalRowsWritten": 0,
    "avgDurationMs": 4197.161798387097,
    "totalDurationMs": 260224.0315,
    "numberOfTimesRun": 62,
    "queryEfficiency": 0.00016227088873640338
  }

{
    "query": "select \"entry\".\"uuid\", \"entry\".\"type\", \"entry\".\"description\", \"entry\".\"userId\", \"entry\".\"createdOn\", \"entry\".\"updatedOn\", \"engineeringEntry\".\"planType\", \"engineeringEntry\".\"location\", \"engineeringEntry\".\"suburb\", \"engineeringEntry\".\"planStatus\", \"engineeringEntry\".\"designer\", \"engineeringEntry\".\"date\", \"engineeringEntry\".\"subdNumber\", \"engineeringEntry\".\"planRegister\" from \"entry\" left join \"engineeringEntry\" on \"entry\".\"uuid\" = \"engineeringEntry\".\"entryUuid\" where \"entry\".\"type\" = ?",
    "avgRowsRead": 37357286,
    "totalRowsRead": 2316151764,
    "avgRowsWritten": 0,
    "totalRowsWritten": 0,
    "avgDurationMs": 4197.161798387097,
    "totalDurationMs": 260224.0315,
    "numberOfTimesRun": 62,
    "queryEfficiency": 0.00016227088873640338
  }

{
    "query": "select \"entry\".\"uuid\", \"entry\".\"type\", \"entry\".\"description\", \"entry\".\"userId\", \"entry\".\"createdOn\", \"entry\".\"updatedOn\", \"engineeringEntry\".\"planType\", \"engineeringEntry\".\"location\", \"engineeringEntry\".\"suburb\", \"engineeringEntry\".\"planStatus\", \"engineeringEntry\".\"designer\", \"engineeringEntry\".\"date\", \"engineeringEntry\".\"subdNumber\", \"engineeringEntry\".\"planRegister\" from \"entry\" left join \"engineeringEntry\" on \"entry\".\"uuid\" = \"engineeringEntry\".\"entryUuid\" where \"entry\".\"type\" = ?",
    "avgRowsRead": 37357286,
    "totalRowsRead": 2316151764,
    "avgRowsWritten": 0,
    "totalRowsWritten": 0,
    "avgDurationMs": 4197.161798387097,
    "totalDurationMs": 260224.0315,
    "numberOfTimesRun": 62,
    "queryEfficiency": 0.00016227088873640338
  }

npx wrangler d1 execute DB --command="select count(*) from entry" --env="preview"
┌──────────┐
│ count(*) │
├──────────┤
│ 6266     │
└──────────┘

npx wrangler d1 execute DB --command="select count(*) from entry" --env="preview"
┌──────────┐
│ count(*) │
├──────────┤
│ 6266     │
└──────────┘

npx wrangler d1 execute DB --command="select count(*) from entry" --env="preview"
┌──────────┐
│ count(*) │
├──────────┤
│ 6266     │
└──────────┘

npx wrangler d1 execute DB --command="select count(*) from entry" --env="preview"
┌──────────┐
│ count(*) │
├──────────┤
│ 6266     │
└──────────┘

npx wrangler d1 execute DB --command="select count(*) from engineeringEntry" --env="preview"
┌──────────┐
│ count(*) │
├──────────┤
│ 6265     │
└──────────┘

npx wrangler d1 execute DB --command="select count(*) from engineeringEntry" --env="preview"
┌──────────┐
│ count(*) │
├──────────┤
│ 6265     │
└──────────┘

npx wrangler d1 execute DB --command="select count(*) from engineeringEntry" --env="preview"
┌──────────┐
│ count(*) │
├──────────┤
│ 6265     │
└──────────┘

npx wrangler d1 execute DB --command="select count(*) from engineeringEntry" --env="preview"
┌──────────┐
│ count(*) │
├──────────┤
│ 6265     │
└──────────┘

Thanks

D

dev•10/7/24, 2:41 AM

This is a quick Bun script to add a migration in d1, but using prisma to calculate the diff. You can adjust this to something else in case you're not using Bun.

import { $ } from 'bun';

// This is the name of the D1 database in Cloudflare and in `wrangler.toml`
const DB_NAME = 'YOUR_DB_NAME';

// Get the migration name from command line arguments
const migrationName = process.argv.slice(2).join('_');

if (!migrationName) {
  throw new Error('Error: Migration name is required.');
}

// Create a new D1 migration
await $`bunx wrangler d1 migrations create ${DB_NAME} ${migrationName}`;

// Find the newly created migration file
const d1MigrationFiles = [...new Bun.Glob(`migrations/*_${migrationName}.sql`).scanSync('.')];

if (d1MigrationFiles.length !== 1) {
  throw new Error(
    `Expected 1 D1 migration file for ${migrationName}, but found ${d1MigrationFiles.length}`
  );
}
const d1MigrationFile = d1MigrationFiles[0];

// Run prisma migrate diff and output to the D1 migration file
await $`bunx prisma migrate diff \
  --from-local-d1 \
  --to-schema-datamodel ./prisma/schema.prisma \
  --script \
  --output ${d1MigrationFile}`;

// Apply the migration to the local D1 database
await $`bunx wrangler d1 migrations apply ${DB_NAME} --local`;

import { $ } from 'bun';

// This is the name of the D1 database in Cloudflare and in `wrangler.toml`
const DB_NAME = 'YOUR_DB_NAME';

// Get the migration name from command line arguments
const migrationName = process.argv.slice(2).join('_');

if (!migrationName) {
  throw new Error('Error: Migration name is required.');
}

// Create a new D1 migration
await $`bunx wrangler d1 migrations create ${DB_NAME} ${migrationName}`;

// Find the newly created migration file
const d1MigrationFiles = [...new Bun.Glob(`migrations/*_${migrationName}.sql`).scanSync('.')];

if (d1MigrationFiles.length !== 1) {
  throw new Error(
    `Expected 1 D1 migration file for ${migrationName}, but found ${d1MigrationFiles.length}`
  );
}
const d1MigrationFile = d1MigrationFiles[0];

// Run prisma migrate diff and output to the D1 migration file
await $`bunx prisma migrate diff \
  --from-local-d1 \
  --to-schema-datamodel ./prisma/schema.prisma \
  --script \
  --output ${d1MigrationFile}`;

// Apply the migration to the local D1 database
await $`bunx wrangler d1 migrations apply ${DB_NAME} --local`;

import { $ } from 'bun';

// This is the name of the D1 database in Cloudflare and in `wrangler.toml`
const DB_NAME = 'YOUR_DB_NAME';

// Get the migration name from command line arguments
const migrationName = process.argv.slice(2).join('_');

if (!migrationName) {
  throw new Error('Error: Migration name is required.');
}

// Create a new D1 migration
await $`bunx wrangler d1 migrations create ${DB_NAME} ${migrationName}`;

// Find the newly created migration file
const d1MigrationFiles = [...new Bun.Glob(`migrations/*_${migrationName}.sql`).scanSync('.')];

if (d1MigrationFiles.length !== 1) {
  throw new Error(
    `Expected 1 D1 migration file for ${migrationName}, but found ${d1MigrationFiles.length}`
  );
}
const d1MigrationFile = d1MigrationFiles[0];

// Run prisma migrate diff and output to the D1 migration file
await $`bunx prisma migrate diff \
  --from-local-d1 \
  --to-schema-datamodel ./prisma/schema.prisma \
  --script \
  --output ${d1MigrationFile}`;

// Apply the migration to the local D1 database
await $`bunx wrangler d1 migrations apply ${DB_NAME} --local`;

import { $ } from 'bun';

// This is the name of the D1 database in Cloudflare and in `wrangler.toml`
const DB_NAME = 'YOUR_DB_NAME';

// Get the migration name from command line arguments
const migrationName = process.argv.slice(2).join('_');

if (!migrationName) {
  throw new Error('Error: Migration name is required.');
}

// Create a new D1 migration
await $`bunx wrangler d1 migrations create ${DB_NAME} ${migrationName}`;

// Find the newly created migration file
const d1MigrationFiles = [...new Bun.Glob(`migrations/*_${migrationName}.sql`).scanSync('.')];

if (d1MigrationFiles.length !== 1) {
  throw new Error(
    `Expected 1 D1 migration file for ${migrationName}, but found ${d1MigrationFiles.length}`
  );
}
const d1MigrationFile = d1MigrationFiles[0];

// Run prisma migrate diff and output to the D1 migration file
await $`bunx prisma migrate diff \
  --from-local-d1 \
  --to-schema-datamodel ./prisma/schema.prisma \
  --script \
  --output ${d1MigrationFile}`;

// Apply the migration to the local D1 database
await $`bunx wrangler d1 migrations apply ${DB_NAME} --local`;

KKyzer Hey, is anyone able to look at these database (9ba874c7-30f8-436c-a357-2b674e0a2...

A

Acе•10/7/24, 12:47 PM

Seems like you don’t have indexes on your columns so it’s reading through the entire table to find the row to join on

A

Acе•10/7/24, 12:50 PM

6266 records in entry multiplied by 6266 records in engineeringEntry, and ran 62 times would equal around 2 billion

AAcе Seems like you don’t have indexes on your columns so it’s reading through the en...

K

Kyzer•10/7/24, 1:30 PM

Ugh, thanks. Think I was assuming the primary key index would have been fine, forgetting the joining table isn't actually using the primary key column

Out of curiosity, with Durable Objects having a KV API, and now an SQL API, what would you get out o

Similar Threads

Similar Threads

Similar Threads