12 ms·
> (Unless it reset to the state the database had when you imported it, instead of clearing it? It might work…) There's no way to know what the db's state was w
by sgbeal 4y ago
> (Unless it reset to the state the database had when you imported it, instead of clearing it? It might work…)
There's no way to know what the db's state was when it was imported without literally keeping a second copy of the whole db solely for comparison's sake, then writing the code to perform the comparison. In the browser storage space, how much space is available for storing such copies is unknown (an unknowable, AFAIK), so we can't simply keep extra copies willy-nilly like we possibly could in an out-of-browser client-side app.
That said: a user can start their session with "BEGIN" and use "ROLLBACK" to revert to the original state.
- coder543 4y agoYeah, I was actually picturing such a feature with an existing database being implemented under the hood using a transaction block around the query input. This idea could also be extended to the most basic case of a completely empty database without modification, instead of just resetting the database, it would just use the same transaction logic. The transaction would be left open until the user either decides to re-run the (presumably modified) query input (causing a rollback first) or to (presumably) end the session by downloading the database (causing a commit first). This behavior would only apply in the auto-resetting “fiddle mode”, of course. Anyways, it was just an idea I was thinking about. I’m sure this idea is not flawless, and you probably have other, higher priority features in mind.