if you use --persist-to I think both Workers can talk to the same local db
if you use --persist-to I think both Workers can talk to the same local db
.sqlite file and run .dump.sqlite file, unless you are referring to a remote D1 Database?.sqlite file. D1 in local development is just a wrapper around that .sqlite file.wrangler directory?db.exec disabled inside pages functions? Works fine locally with wrangler, but not after deployed..exec, do you get a db.exec is not a function error? I'm getting that, wondering if it's the same thing you are seeing and if you found a workaround?D1Database.exec method.prepare() nd the migrator tries to use the base sqlite-core dialect, it uses transactions which aren't supported by d1 : https://github.com/drizzle-team/drizzle-orm/blob/main/drizzle-orm/src/sqlite-core/dialect.ts#L768-L812

D1's REST API doesn't involve a Worker, which is why it's considerably slower above in the chat. Oy vey.d1 migrations apply <DB> and it always did a check to see if there where any new migrations to apply and applied them (if none, then did nothing).database_id in wrangler.toml in public repo? If no is there any convenient alternative rather than using a separate secret wrangler.toml? Thank you.wrangler/state/... but you can set the path explicitly when you start the worker with --persist-to={path}import { json } from "@sveltejs/kit";
import { ACCOUNT_ID, CLOUDFLARE_API_KEY, CLOUDFLARE_EMAIL, DATABASE_ID } from '$lib/server/secrets.js';
/** @type {import('./$types').RequestHandler} */
export async function GET({ platform }) {
const url = `https://api.cloudflare.com/client/v4/accounts/${ACCOUNT_ID}/d1/database/${DATABASE_ID}/query`;
const options = {
method: 'POST',
headers: {
'Content-Type': 'application/json',
'X-Auth-Email': CLOUDFLARE_EMAIL,
'X-Auth-Key': CLOUDFLARE_API_KEY
},
body: '{"sql":"SELECT * from test"}'
};
const resp = await fetch(url, options);
const data = await resp.json();
return json(data);
}