i'm curious is the limit of d1 queries 1000 for unbounded?

also does it not support ON CONFLICT DO NOTHING

I guess maybe i can use INSERT OR IGNORE

https://www.sqlite.org/lang_conflict.html > The ON CONFLICT clause is a non-standard extension specific to SQLite that can appear in many other SQL commands. It is given its own section in this document because it is not part of standard SQL and therefore might not be familiar. Guessing that's cause it's non-standard, yeah.

Thanks all! let's ignore for `Object.values `syntax for now.. I'm curious for why worker

WritableStream

(controller.error) not beahvior same as Chrome....

sanity check, if I do

cache.put

in a Worker with a URL like

http://private.invalid/hello

, can I purge it in every Worker datacenter using

https://api.cloudflare.com/client/v4/zones/{identifier}/purge_cache

with the URL set to

http://private.invalid/hello

even though that isn't a "real" zone? https://developers.cloudflare.com/workers/runtime-apis/cache/#put https://developers.cloudflare.com/api/operations/zone-purge#purge-cached-content-by-url

Yeah as long as it isn't an active zone on Cloudflare https://developers.cloudflare.com/workers/learning/how-the-cache-works/#single-file-purge--assets-cached-by-a-worker

I'm struggling to find any documentation on keep alive connections for workers If I do

fetch(url_a)

, will requests in the same request re-use the same connection to

url.host

? Like e.g. Chrome What about between different requests that connect to

url.host

?

You probably wouldn't want to look for information specifically relating to Workers - Workers or not, requests to origins go through the normal Cloudflare flow.

example.invalid will never be an active zone though, so I should always be safe I think?

It's a fairly old post, so https://blog.cloudflare.com/how-we-built-pingora-the-proxy-that-connects-cloudflare-to-the-internet/ might be more accurate on implementation details (as this replaced the NGINX instance that did origin requests)

Ahhh, didn't expect it to be handled outside the runtime like that. Very nice, makes sense 🙂

Will read that post in a bit more detail, but from the diagram it looks like what I'd expect. Great, thanks for your all your answers kian!

Yeah you would be

I don't recall if this diagram is truly accurate, but you can think of it like this.

When a Worker makes a subrequest, it'll go through everything again (FL -> Cache -> Pingora -> Origin) - so other than you get a fancy

CF-Worker

request header added so origins can identify your Worker opposed to other Workers, it's basically identical.

From a Worker, is there an easy way to get the closest R2 region without resorting to using a load balancer?

Maybe try creating a bucket and then reading the region?

that will break as soon as there's accidentally 1000 concurrent requests though 😛

Then cache the mapping in KV?

oh so only concurrent? if you wait for them to finish you'll be good?

const stmt = await DB.prepare("SELECT * FROM balances WHERE thing = ?1 "); const existingRecords = await stmt.bind(thing, ).all(); will this result in multiple queries each time existingRecords is used? I keep having my application time out and i think it's from too many requess

i notice theres a .run method

maybe there's an easy way i can just migrate the "seed" data that i need to the db from my local host, Basically the app scapes a whole bunch of data on initial deployment, but after it's deployed it only needs to get incremental updates, it works fine on my localhost but then i deploy it and either only part of the data shows up in the db, or I get an application error and again only part of the data shows up lol

this does not list the 2023-05-15 compatibility date. https://developers.cloudflare.com/workers/platform/compatibility-dates/

cursor has some interesting things to say

what happened? [cron triggers] no i didn't change the code

¯\_(ツ)_/¯

you'd need to check logs