Is it possible to dynamically get a d1 database(usecase for saas)?
Is it possible to dynamically get a d1 database(usecase for saas)?
HD1 has built-in support for creating and restoring backups of your databases, including support for scheduled automatic backups and manual backup …
HAs a binding? No
HAs a call to the API, yes
Slike
env.dbNamespace.get('db-id')HYeah, you can’t do that
AI get around 200ms of latency when querying the database (living in France). Is the SQLite database right know hosted in US?
AFrom what I understand there is no replica yet right?
ZAFAIK the database is hosted wherever the DO behind it gets created, which is usually near to where the first request is made. Is the latency lower when you are requesting from the US?
ZNot yet!
THi, Is some kind of
Thanks
REGEXP extension already installed (and I did not yet succeed to call it), or will it be later?Thanks
Mis d1 support index by column?
MSQLite Tutorialadmin
In this tutorial, you will learn how to utilize SQLite index to query data faster, speed up sort operation, and enforce unique constraints.
JIs there a way to see where the D1 is hosted? I know replication is not yet switched on but I would love to get a sense of things. Also, is it possible to move the DB, perhaps by recreating it? Super excited about D1.
JAlso. Random observation, sqlite very powerful paradigm for user/org specific things. So if product is like Salesforce, each org could evolve schema with fields they want to use for their db. Opens door to amazing tooling! Not yet supported but interesting angle - dynamic bindings?
CI thought there was
C“Account:D1”
JI was using D1 for the first time in a while and came across a D1 error that was confusing:
This doesn't work because
Unfortunately, all that's thrown is
Are there some docs that help explain the JS API? Or maybe some docstrings could be added to the types to help explain when to use each method?
This doesn't work because
run() apparently isn't allowed for SELECT (but I forgot I needed to use all() or first()).Unfortunately, all that's thrown is
D1_ERROR (with nothing in e.cause.)Are there some docs that help explain the JS API? Or maybe some docstrings could be added to the types to help explain when to use each method?
JThat's true, deff could have been logging it wrong. Thanks!
DTypes could also be converted into generics for
D1PreparedStatement to indicate what statement it was more precisely, something like https://tinyurl.com/d1-generic-types-ts-playgroundThe Playground lets you write TypeScript or JavaScript online in a safe and sharable way.
Mcc @geelen
Dyeah there are definitely edge cases, but I think there are <10k possible combinations of statement types, so it might be doable - the playground is just an example for me to check if it's possible without regex types literals, so I only did some very basic tests
HI'm experimenting with running D1 migrations off of Pages CI/CD using wrangler apply with an API token for D1. When I ran the command it applied the first script and then failed on the second script with Internal Error 7501. Does anyone know if there are limitations to doing this: e.g. it can only run one script at a time etc.
HFYI: I ran the same scripts later from the terminal from my local development mac and everything ran smoothly with changes made to my D1 instance on Cloudflare: so I know that the scripts do not have bugs.
HYep. Thanks for the response. Of course this means that we cannot push out code that works with migrations. In such a case I will opt to run migrations manually to make sure the database is updated and then push code to GitHub to update the pages code. Real shame though as it breaks the possibility of truly automated CI/CD
HI really do not believe in having dozens of if then switch cases strewn all over the code looking at schema. I believe that's a recipe for unmaintainable code. However, I'll go for the practice of pushing out schema changes that work with the old code, then pushing out code that works with the new schema and then deleting the old schema. However, even here, i'd rather do it by pushing schema changes to GitHub and then having CI/CD implement the changes because anytime you have a human do manual commands on a live site you introduce a massive risk factor of mistakes and failure. So IMHO having Wrangler randomly fail and thinking that this is normal does not reflect well on the perception of reliability and production readiness. However, having said all this, I have faith that given D1 is only Alpha, these problems will be resolved hopefully when D1 goes beta. Having Wrangler reliably work with CI/CD is essential to a developer system that can be relied on and is ready for prime time.
