Hey, I can't make a new durable object : ``` Cannot create binding for class 'Trainer' because it i
Hey, I can't make a new durable object :
But if I try to add it
In my wrangler I have
I already did it once and then I deleted my durable object via dashboard, how to remake one ?
14 Replies
Try just running
wrangler deploy
Yeah that's what gives me
and I tried with different wrangler version, currently i'm on 3.78.12
Use a different tag, for example tag = “v1.1”
Well I finally resolved the issue by deleting the existing worker, made a new worker with different name, then migrate my page on the new worker
But ty! I'll try
I tired: https://discord.com/channels/595317990191398933/773219443911819284/1290231219291689050 but the number was not changed.
Unknown User•7mo ago
Message Not Public
Sign In & Join Server To View
Thanks but I have read all the materials you guys provided.
The reason why doing this is to remove errors.
I understand that. But what I am saying is that only one read should not consume this number of read because it does not make sense to scan other tables when I just want to get one row. FYI, there is no foreign key in every 8 tables and there are only 6 records in total
I will try researching good indices anyway. Thanks for the answer.
Unknown User•7mo ago
Message Not Public
Sign In & Join Server To View
Cool 😎 thank you for the info!
Just an addendum here in case anyone sees this in the future that this is for typing only - if the row isn't actually a User no error will be thrown, it will show as a User to Typescript but not actually be a User object 😄
DNS over Discord: GitHub
View the DNS over Discord source code on GitHub at https://dns-over-discord.v4.wtf/github
Hi guys,
Is the latency between the Worker and the Durable object expected to be around 100-160ms provided that they both are in the same location?
Does write coalescing apply to SQLite storage? I'm particularly worried about the atomicity described in the docs (and quoted below) for non-SQL storage.
If you invoke put() (or delete()) multiple times without performing any await in the meantime, the operations will automatically be combined and submitted atomically. In case of a machine failure, either all of the writes will have been stored to disk or none of the writes will have been stored to disk.
AFAIK, no, but it doesn’t have to, since the storage is synchronous anyway