env.DB.prepare() does not send any type of request IIRC, you have to explicitly add .all() or .first
env.DB.prepare() does not send any type of request IIRC, you have to explicitly add .all() or .first() to send it to the DB
KYeah it just constructs a
D1PreparedStatement object
V@skye_31 persistTo only sets the folder in which D1 will be stored but somehow I still need to figure out the uuid of the database, how do you do that?
Vsettings
persistTo to like test will place the db into test/v3/d1/{uuid} where uuid is the id of the database in the .toml file. Not sure how should I access that in the testVin like a non-hacky way
IYeah, Iwas sure about no queries, but maybe...
MBoth @rozenmd and I were chatting about the state of testing (our excuse: we're in alpha). We're working through a design but I think the right approach is to be able to call:
What else are folks wanting here? We want avoid local testing drifting from production APIs, and you shouldn't have to think about where
createTestDatabase(): Promise<D1Database>runMigration(db: D1Database, name: string, dir?: string): Promise<void>deleteTestDatabase(db: D1Database): Promise<void>
D1Database allows you to call the regular .prepare, .exec, etc methods on top.What else are folks wanting here? We want avoid local testing drifting from production APIs, and you shouldn't have to think about where
.state is stored.VI think if we are able to do migrations / cleanup on the database outside of the unstable_dev() then most of the use-cases should be covered
VAs for my problem I think I figured it out, by setting a preview_database_id="local" in the .toml file now I know the exact path of the db.sqlite file and thus able to execute migrations on the db before tests start running
MYeah, if you can run
runMigration and it mirrors wrangler d1 migrations apply <name> -> that gives you the tools you need to run a series of migrations from within CIVthat would be awesome yes
Vwrangler d1 migrations apply run in CI's without like logging into cloudflare? because i might just run it as a shell command as of now to make my test setup less brittle and later swithc to the programatic runMigration API once its outMmigrations apply defaults to remote.VVhere is my current code, looks to be working allright
Vlet me know if you see anything wrong
MLooks pretty good to me.
MI've stubbed out some basic docs here - https://github.com/cloudflare/cloudflare-docs/pull/9471
- but need to improve with a full example.
Vwith the code above i do not need to use
preview_database_idVas simply setting the
persistTo to a different temporary path works. In the docs above if an user would run tests with preview_database_id set but not a custom persistTo they would mess up their development databaseMYeah, that makes it a bit easier in that regard. I think we need to think through how we want
preview_database_id to interact w/ programmatic testing here.M(Sometimes you might want that to happen)
Vhonestly what would be the perfect API for testing is to be able to have unstable_dev run D1 as in-memory only and have a function to run migrations on this in-memory sqlite db
Mand/or we should just generate a 
/tmp/<some random ID> file that gets thrown away by your OS. That way, if you have a larger DB, we don't eat all of your CI containers' memory Vsure, that would be just as good
Ahow can I seed local
D1 sqlite? I was using bun sqlite where I create a local db.sqlite file and interact with it using the imported client. In the case of Cloudflare & wrangler, I'm a little confused as to how I can create and seed a local sqlite
Amy
dev commandwrangler.json
AI've tried this. It says to use
seeding a local sqlite
--persist-to=/path/to/file to persist data to a specific location but no luck and on seeding I couldn't find any relevant info.seeding a local sqlite
CWhat version of wrangler on you on?
AAis there a way to run a one off typescript file that seeds the db? Before wrangler I was running a
prestart script that runs a ts file to init local sqlite and seed itV--persist-to is only a folder, so for example by using --persist-to=/temp the actual db file will be stored in /temp/v3/d1/x.sqlite
also you won't find the file right away, the db has to be accessed first for the file to be created
also you won't find the file right away, the db has to be accessed first for the file to be created
Vtake a look at
wrangler d1 migrations, you can use a migration to seed the database or if you want a more programatic approach scroll up a bit, we had a discussion about possibilites just a few hours agoAok will try scrolling up. My attempt was to make seeding a worker endpoint that I call by hitting the endpoint but will see if I find a better approach
Aah gotcha. The wording in the doc made me think I can specify filename
--persist-to=/path/to/fileMIf you set
preview_database_id (per https://developers.cloudflare.com/d1/platform/migrations/#wrangler-customizations) and use wrangler d1 migrations apply <db-name> --local -> you can apply migrations locally to seed the DB. As above, you can also do that programatically via your test harnessDatabase migrations are a way of versioning your database. Each migration is stored as an .sql file in your migrations folder. The migrations folder …
AI don't see the db client to interact with sqlite being used in the section or any sql queries to seed being done. I assume this section expects me to run migrations through cli first, but what if I want to seed programmatically
Ais it possible to tell wrangler to use a specific
name.sqlite file?AThank you for the help by the way
Athat can run a ts file and pass it the context with the database client? I will try that
Alooks promising
Aok fair. That should work too
MYou can invoke
wrangler d1 migrations inside your tests: the example shows that.MAsweet, thank you
Awhen I created a new local db just now, it said binding is
db. Is there a way to change that by just changing binding in wrangler config?
Duse the --local option
Dso something like
wrangler d1 execute --local --comand="SELECT NOTHING"