- From: Evan Stade <notifications@github.com>
- Date: Mon, 03 Jun 2024 17:31:33 -0700
- To: w3c/IndexedDB <IndexedDB@noreply.github.com>
- Cc: Subscribed <subscribed@noreply.github.com>
- Message-ID: <w3c/IndexedDB/issues/420/2146348861@github.com>
So I don't think that we're likely to want to surface an API for IDB that deals with an implementation detail like the fact that LevelDB requires periodic compaction, and also websites should not need to call `purge()` to paper over a poor user agent implementation. But I am going to hazard a guess that you've encountered this issue on Chromium in particular. If so, can you file a bug report on crbug.com and fill out the template with repro steps etc, or just give as much detail as possible about the behavior you're seeing? Because when I write a test app that just writes a bunch of stuff to IDB repeatedly, the size doesn't necessarily behave "rationally" but does not grow without bound either. > I don't even know if all vendors are using LevelDB (it'd be funny, as WebSQL died to not be dependent on SQLite and if that's the case here everyone is dependent on LevelDB logic?!) They aren't, and FWIW WebSQL was deprecated largely because arbitrary websites can't be trusted to inject arbitrary SQL. User agents do use SQLite for other things so there's already that dependency in terms of internal browser usage. In Chromium, IndexedDB may one day use SQLite as well. -- Reply to this email directly or view it on GitHub: https://github.com/w3c/IndexedDB/issues/420#issuecomment-2146348861 You are receiving this because you are subscribed to this thread. Message ID: <w3c/IndexedDB/issues/420/2146348861@github.com>
Received on Tuesday, 4 June 2024 00:31:37 UTC