the console tab? can you DM me what you were trying to run, I'll try fix it tomorrow
the 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
MWhatever CF ends up doing as far as replicas go, hopefully it'll be flexible. For example, I operate a (relatively speaking) small DB for a volunteer organization which is local to a certain city's metropolitan area. Therefore, we have no need for any kind of replication (as pretty much all requests will hit the same PoP), and we are very cost sensitive, so being able to forgo replication would be a huge plus for us.
Mfeature request for the D1 dashboard interface: when displaying the contents of some table, it'd be really helpful if there was some way to differentiate between a NULL value and a text field which contains an empty string or whitespace, to avoid this situation:
Myeah good point