I'm getting this error when using hono on a durable object that has d1 bound. Not getting it on a wo

I'm getting this error when using hono on a durable object that has d1 bound. Not getting it on a worker:

Trace: TypeError: Fetch API cannot load: /get/rows
    at d1-beta-facade.entry.js:1528:16
    at Hono.dispatch (d1-beta-facade.entry.js:1192:15)
    at Hono.fetch (d1-beta-facade.entry.js:1093:19)
    at Object.fetch (d1-beta-facade.entry.js:1743:28) {
  stack: TypeError: Fetch API cannot load: /get/rows
    at…at Object.fetch (d1-beta-facade.entry.js:1743:28),
  message: Fetch API cannot load: /get/rows
}

Trace: TypeError: Fetch API cannot load: /get/rows
    at d1-beta-facade.entry.js:1528:16
    at Hono.dispatch (d1-beta-facade.entry.js:1192:15)
    at Hono.fetch (d1-beta-facade.entry.js:1093:19)
    at Object.fetch (d1-beta-facade.entry.js:1743:28) {
  stack: TypeError: Fetch API cannot load: /get/rows
    at…at Object.fetch (d1-beta-facade.entry.js:1743:28),
  message: Fetch API cannot load: /get/rows
}

Trace: TypeError: Fetch API cannot load: /get/rows
    at d1-beta-facade.entry.js:1528:16
    at Hono.dispatch (d1-beta-facade.entry.js:1192:15)
    at Hono.fetch (d1-beta-facade.entry.js:1093:19)
    at Object.fetch (d1-beta-facade.entry.js:1743:28) {
  stack: TypeError: Fetch API cannot load: /get/rows
    at…at Object.fetch (d1-beta-facade.entry.js:1743:28),
  message: Fetch API cannot load: /get/rows
}

Trace: TypeError: Fetch API cannot load: /get/rows
    at d1-beta-facade.entry.js:1528:16
    at Hono.dispatch (d1-beta-facade.entry.js:1192:15)
    at Hono.fetch (d1-beta-facade.entry.js:1093:19)
    at Object.fetch (d1-beta-facade.entry.js:1743:28) {
  stack: TypeError: Fetch API cannot load: /get/rows
    at…at Object.fetch (d1-beta-facade.entry.js:1743:28),
  message: Fetch API cannot load: /get/rows
}

Has anyone seen this before? The route just does a

return c.text("hey")

return c.text("hey")

return c.text("hey")

return c.text("hey")

kian•1/28/23, 2:45 PM

I’d normally refer people to https://forms.gle/ukpeZVLWLnKeixDu7 but that doesn’t have D1 as an option

Google Docs

Cloudflare Developer Platform: Limit Increase Request Form

Want to increase the limits of your current plan? Let us know what your requirements are here.

kian•1/28/23, 2:45 PM

Erisa•1/28/23, 2:45 PM

honestly its probably a case of ask nevi

captain•1/28/23, 6:34 PM

just started my first D1 integration which is all about transitioning KV to D1. My KV makes use of an auto expire which saves me on a request, just wondering if there is something like that (or will be something like that) in the future? I'm sure its possible for me to create an "expire" column and run a cron query to remove the matches every so often, but was looking for some something that would not hit my quota so much

Original message was deleted

captain•1/28/23, 8:01 PM

a few of the reason's i am reviewing D1: speed of being able to read something i have written, and speed of delete, the limit of the metadata. Is the speed of reading data after writing alot faster than KV? And do you know if they have come up with a pricing strategy for storage, reads and writes?

Original message was deleted

captain•1/28/23, 9:56 PM

is the speed currently faster than kv?

Original message was deleted

captain•1/28/23, 9:57 PM

after the first write, is the availability of the data written via D1 faster than kv from what you have noticed? (only in regards to first write to read )

Unsmart•1/28/23, 9:58 PM

D1 is strongly consistent atm so read after write is immediate

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

Read replicas will eventually become a thing where reads wont be immediately available after write. For the most part though kv writes are immediately visible unless you had previously read that value in which case the result wouldve been cached (so a first write to read for kv is for the most part immediately available there may be some delay for cross world reads given 2 central stores for kv)

ZZiga Zajc Do you think reading from replicas would have separated pricing scheme?

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

Reading from Replicas will probably just be classed as a read, since there is basically no reason you should be reading from the main shard

ZZiga Zajc yeah D1 is also replicated on multiple data-centers anyways.

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

Not yet

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

But

UUnsmart Read replicas will eventually become a thing where reads wont be immediately ava...

captain•1/28/23, 10:22 PM

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...

captain•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...

captain•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.

captain•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

captain•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

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

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

captain•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

captain•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...

captain•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

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

i learned that this week lol

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

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

captain•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.DBenv.DB still and work great
If you're using a _worker.js then you'll need to bundle it --bundle--bundle

I'm getting this error when using hono on a durable object that has d1 bound. Not getting it on a wo

Similar Threads

Similar Threads

Similar Threads