thats what I would do, might be harder in practice
thats what I would do, might be harder in practice
JAny regular process which involves dropping and recreating millions of rows of a table should be rethought architecture-wise, regardless if this was D1 or Postgres. If I was stuck on such a process, i'd probably run a blue/green deployment on this table to keep both pre-post hot to avoid migration downtime.
CstartDataUUIDs is a array of uuids
Gyea often times its easier to re-think the issue rather then solve obscure edge cases
ZThat's an option, but one that will suck once D1 global replication exists
ZGiven that will presumably replicate over time, and increase the PoP's it exists in, replacing the entire database will destroy that replication and you'll start from step 1
ZSomething like this would be totally fine in postgres, it's an extremely simple operation that won't impact the database whatsoever
IOnce it lands, D1 replication is extremely quick so this should still be a reasonable method of replacing the DB
ZI've not seen any info on that tbh
ZI imagine the process of replication is fast, but I expect the process of learning where to replicate too is not necessarily as fast
ZAnd switching out your DB and dumping all load onto a single node while it replicates out is not going to be great
II can't really say too much at the moment other than the fact that switching out a DB will still be a reasonable thing to do once replication lands 
ZWe'll see whenever that lands I guess, regardless, dropping a table should not be something that takes out a production database 
Gif its anything like other platforms the writes go to all replicas without any work on your end
Gand it's basically instant
ZIf you replace the entire database, there are no replicas
Gbut like they said can't speak for something we don't have
ISure but if you want zero downtime, you duplicate the DB, drop the table, and switch the "connection" (binding)
ZYes, that is something we've considered, it's just more work
ZWe're already having to work around multiple other issues that we didn't expect lol
γHi. I encountered a consistent issue when editing a row in a D1 table via the dashboard. Attempting to edit the following string causes a 404 Bad Request:
data.txt51B
γI'm not exactly sure which character is triggering the error β it might be due to a special character or even an invisible whitespace β but the issue is 100% reproducible when trying to update a row containing this exact value.
TI'd love to hear more. What other issues did you unexpectedly encounter?
ZBulk import API causing the database to be unusable (which is documented to be fair), the D1 API having severe rate limits (worked around by using our own worker as a proxy for SQL commands), some issue internally with D1 causing huge latency after we replaced a bulk of the data within the database that the team fixed
ZWe are using D1 in a slightly abnormal way, as a lookup table basically, so you probably won't experience the same problems if you're using it as a more traditional database 
TThank you!
Gdoes that end up in the url of the edit page?
γYes, the issue happens when click "Update" on a row that contains that string the value ends up in the URL, and that's when the 400 error oCcurs.
So it seems like the string being placed in the URL is causing the problem.
So it seems like the string being placed in the URL is causing the problem.
Gits likely a character that can't be in a url, like the one used as a space character, the browser is interpreting it as a space etc and that causes the 404
Gcan't say which specific one is the issue but I'd say thats the issue IMO
Jout of curiosity, does anyone know how D1 accomplishes autoincrement given its distributed nature?
JIt doesnβt - d1 isnβt distributed today. Your db exists in a single region
Jah, so the
--locationgood to know, thank you @James!
JCurrently yep. The team has talked a lot about read replicas though, so I wouldnβt be surprised if we see something there soon 
Jawesome, i'll save my question for then, ha.
Greally hoping for more d1 news given the outerbase stuff but not holding my breath
JThat would be pretty great, fingers crossed!
Onoway read replicas
Zit's happening
SAre there any issues with D1 currently?
SI'm pushing stuff but they don't show up on the API
L
LNext question, when does this come to DO-based SQLite storage?
LD1 is the customer zero of DOs 
So, once we see it's good enough with D1 and iron out some things, DOs will get some version of it too.
So, once we see it's good enough with D1 and iron out some things, DOs will get some version of it too.LI would encourage people to try this out, and please give us feedback. Tell us cases it broke for you, or didn't do what you expected. Note that it's "beta". We are aware of some specific issues and are fixed as we speak to be rolled out over the next few weeks, so do your own testing to see if fits your workloads too.
CIMO at least for me the session API adds waaay too much work to bother implement it. Ideally I was hoping cf would just figure this out like turso does
CRight now I simply use cache & KV which give me pretty much the same results but it's simpler and easier to understand (I know it's eventually consistent, but that works for me)