let me follow up with that. I have a dashboard. Currently a remost api will post some data to my wor

let me follow up with that. I have a dashboard. Currently a remost api will post some data to my worker, it gets processed and with a specific client ID and saved. Then to a specific client will have their dashboard open which is refreshing every 15 seconds or manually if the client clicks refresh. I'm doing this with KV, and it works, but sometimes the delay is 15-30 seconds. On ave will D1 be ALOT faster or are you saying its gonna be the same sort of the delay in the future eventually (anybody can chime in)

Ccaptain let me follow up with that. I have a dashboard. Currently a remost api will post...

Hello, I’m Allie!•1/28/23, 10:23 PM

We don’t know how fast D1 will be in the future. We know that it will be faster than it is now, but we can’t guarantee whether the end-product will be faster or slower than KV is now

Hello, I’m Allie!•1/28/23, 10:24 PM

Oh wait…

Hello, I’m Allie!•1/28/23, 10:24 PM

This is about the KV Cache, isn’t it…

Hello, I’m Allie!•1/28/23, 10:25 PM

So yeah, in a cache-less setup, D1 would probably even now be faster than KV

Hello, I’m Allie!•1/28/23, 10:25 PM

At least for updates

Hello, I’m Allie!•1/28/23, 10:25 PM

Individual responses would be pretty slow though

Unsmart•1/28/23, 10:26 PM

Ah so you meant read write read not write -> read. Yeah KV will by default cache a read for 60s so the reason it takes that long to see the new data is the fact that it is cached. (You are probably not seeing it cached for a full 60s because low request rate and probably a lower plan tier I assume). At the current moment D1 is strongly consistent so a read -> write -> read will be immediate. Read replicas once they become a thing I would assume are going to be push based so it should in theory show a new write faster.

UUnsmart Ah so you meant read write read not write -> read. Yeah KV will by default cache...

captainOP•1/28/23, 10:26 PM

(free tier)

UUnsmart Ah so you meant read write read not write -> read. Yeah KV will by default cache...

captainOP•1/28/23, 10:27 PM

got it, i was confused because you mentioned something about read replicas, but for my use case it sounds like D1 is the way to go.

Unsmart•1/28/23, 10:28 PM

D1 or DO yes. You could basically use DO as KV with strong consistency.

captainOP•1/28/23, 10:29 PM

i was thinking D1 would be easier to set up and cheaper?

Ccaptain got it, i was confused because you mentioned something about read replicas, but ...

Hello, I’m Allie!•1/28/23, 10:29 PM

Though also, if you need just a Key-Value store, R2 might be the more stable option

Unsmart•1/28/23, 10:29 PM

Easier to setup - yes. Cheaper - not sure

Hello, I’m Allie!•1/28/23, 10:29 PM

You can also slap a cache on top, configured to expire faster, so you get billed less

captainOP•1/28/23, 10:30 PM

so in my scenario GENerally, my clients will be poling server and get no data, then something might come in and that row would be active on average 50 minutes then go away

captainOP•1/28/23, 10:31 PM

and then database would be empty with the data then being moved to KV (could R2 in future)

captainOP•1/28/23, 10:32 PM

i was thinking D1 would be cheaper because as long as the DO is "on" then its getting charged where as the I am thinking D1 won't be charged for simply creating a database

captainOP•1/28/23, 10:32 PM

but if D1 gets charged for creating a database with no rows then there goes my theory

Ccaptain but if D1 gets charged for creating a database with no rows then there goes my t...

Hello, I’m Allie!•1/28/23, 10:33 PM

We also have no info for how D1 is billed atm, so we can’t comment there

Unsmart•1/28/23, 10:33 PM

DOs are only charged when you have an active request being processed. The duration charge when all you do is storage is basically nothing and I normally dont include in my cost estimates tbh (other than maybe some rounding to the next $10/$5 lol)

Unsmart•1/28/23, 10:35 PM

Fwiw D1 is built on top of DOs so for any cost estimates I would almost assume it probably costs the same or more

(but thats just my opinion and I have no idea what it actually will be)

UUnsmart DOs are only charged when you have an active request being processed. The durati...

captainOP•1/28/23, 10:35 PM

got it. Well I have yet to play with one, but for now i was toying with the D1 idea...thought i was gonna have it done on monday...but then had to convert my whole giant project to modules from a server worker

Original message was deleted

captainOP•1/28/23, 10:36 PM

i learned that this week lol

captainOP•1/28/23, 10:36 PM

but now my project is much faster and takes way less time to build

captainOP•1/28/23, 10:36 PM

so its good

Noel•1/29/23, 10:01 AM

just came here to ask this ^

CCarlson Orozco Hello everyone, does anyone know if there's an update on this? https://community...

Max (@rozenmd)•1/29/23, 2:54 PM

it's in the backlog, I've been nudging to get it done

Walshy•1/29/23, 3:36 PM

@yuimaru Removed your message since you posted your Turnstile key but as for why that env is there, that's how the D1 shim needs the env to be. It should be available at

env.DB

env.DB

still and work great
If you're using a _worker.js then you'll need to bundle it

--bundle

--bundle

Original message was deleted

James•1/29/23, 3:37 PM

What's up?

kev-ac•1/29/23, 9:18 PM

Maybe API bug: I have one D1 database which is at capacity (~104MB, 1 Table). When I try to open it in the dashboard the "tables" tab thinks some seconds and then nearly always fails with

API Request Failed: GET /api/v4/accounts/{ACCOUNT_ID}/d1/database/{DATABASE_ID}/table (500)

API Request Failed: GET /api/v4/accounts/{ACCOUNT_ID}/d1/database/{DATABASE_ID}/table (500)

.

API Response:
{
"result": null,
"result_info": null,
"success": false,
"errors": [
{
"code": 7501,
"message": "Internal error"
}
],
"messages": []
}

James•1/29/23, 9:26 PM

I'm seeing similar errors on a couple of my test D1 databases too, even just hitting

/d1/database/dc00d2ec-2c06-460d-a6e4-01cfe42f93e4

/d1/database/dc00d2ec-2c06-460d-a6e4-01cfe42f93e4

on the dashboard

Erisa•1/30/23, 12:49 PM

afaik that API is undocumented and could break/change at any time, and also im pretty sure it would be slower latency-wise in a lot of cases and has rate limiting applied

Erisa•1/30/23, 12:50 PM

if its just an occasional query thats not latency-sensitive youll be fine, but if youre querying on every request for example i would strongly recommend using the worker binding

Erisa•1/30/23, 1:11 PM

very very useful for one-offs, but yep definitely dont rely on it for production traffic

Erisa•1/30/23, 1:33 PM

none that im aware of

Erisa•1/30/23, 1:33 PM

its mostly useful to workers, which dont really support c#

Erisa•1/30/23, 1:34 PM

you could, but keep in mind the above caveats
generally i would recommend instead using a worker as a proxy for d1, rather than using the api for anything more than one-offs

Max (@rozenmd)•1/30/23, 7:49 PM

also new in wrangler 2.9.0:

wrangler d1 execute --json

wrangler d1 execute --json

wrangler d1 list --json

wrangler d1 list --json

let me follow up with that. I have a dashboard. Currently a remost api will post some data to my wor

Similar Threads

Similar Threads

Similar Threads