I've encountered some odd/buggy behavior and HTTP 500 errors coming back from the API
I've encountered some odd/buggy behavior and HTTP 500 errors coming back from the API
Myep
Mjust tell us here
MI'm ridiculously online
Mif it's returning a 7501 error most of the time you can safely retry
MI was just using the dashboard interface to set up my tables, trying to INSERT INTO more than 2-3 values at a time causes a 500, and now whenever I load the list of tables I get 500 as well
Mthe weirdest behavior was the console showing internal error but the operation succeeded
Mthe console tab? can you DM me what you were trying to run, I'll try fix it tomorrow
Mofc now I can't get it to reproduce the error I was getting in the console tab ...or the 500 error when trying to load the tables tab
Mguess it's working then lol
Myeah might be that bug where it's safe to retry
Mah... figured it out - was my own mistake because I primarily use MySQL. I tried to do the following, which works in MySQL but doesn't work with SQLite
MFor whatever reason that produced a 500 error when I first tried it, but now it correctly returns the SQLite error
MI still get sporadic 500 errors when I try to load the tables tab, can't figure out why. I'll go ahead and send over the database info in case that's of any help
HGenerally yes, but many apps just don’t work very well on a KV model
EI'm personally expecting it somewhere in between R2 and KV pricing wise, as D1 isn't distributed globally like KV is, and the processing cost will be covered by the worker executing the query, but I've no idea all the stuff they're doing behind the scenes for transnational requests etc which might drive it up.
EI hope it's close to R2 pricing wise, with replicated read replicas costs based on usage, and the compute costs being one of the higher parts but that's basically the worker executing the query.
Although I don't think it'll be like that, they'll likely need something funky behind the scenes to support D1 instances >100MB as that's more than a worker can store in memory, so perhaps it'll be simple pricing for small D1 instances and complex pricing for larger D1 instances? Who knows
Although I don't think it'll be like that, they'll likely need something funky behind the scenes to support D1 instances >100MB as that's more than a worker can store in memory, so perhaps it'll be simple pricing for small D1 instances and complex pricing for larger D1 instances? Who knows
Wwhat do you mean?
EI'd interpreted that as they'll replicate it where/when there's sufficient demand, not that it'll be auto replicated like KV is
EI'd honestly prefer D1 not be replicated to every datacentre, or at least for that to be configurable, that'll really drive up the costs and make it unsuitable for some use cases that are more cost sensitive.
HKV doesn't replicate
HOr at least not at that scale
HIIRC, it is going to be replicated to wherever there is a large concentration of accesses
HMe? That was the post that Rabbit posted above
HAs in, not everywhere, but if a large amount of requests hit LHR, then it might spawn a replica there
MHelps us to gauge folks' expectations haha
HNeeds to be in memory in every edge metal :lul:
EYeah sorry I thought it was obvious myself/rabbit were just speculating, didn't intend any harm from that
HSQLite from Disk, like Fly's LiteFS.
MGlen mentioned something about that a few days back
