4 ms·

If you consider the design space, “resetting the state every time” is exactly how basically every other “fiddle” app works. If JSFiddle were just duplicating yo

If you consider the design space, “resetting the state every time” is exactly how basically every other “fiddle” app works. If JSFiddle were just duplicating your code into the javascript VM each time you hit run, you’d be overwhelmed with pointless errors about duplicate identifiers immediately. The idea is to let you build up a reproducible, shareable outcome. So, if you want to share a demo of how you might create a few tables and perform join queries, you can easily and interactively assemble that if the state resets to zero each time you run the set of queries. It’s probably a completely different way to use the application than you were considering if you don’t see the point of it, but I’ve actually used another tool exactly like this in a job interview that involved testing SQL knowledge. Would it be useful for manipulating an existing SQLite database? Probably not. (Unless it reset to the state the database had when you imported it, instead of clearing it? It might work…) > However, the app now has a button to nuke the db. Awesome! > In related news: if any text in the input field is currently highlighted, only that text is submitted via the Run button or ctrl-/shift-enter. That would certainly be helpful towards the use case I’m describing, although I can imagine that UX being difficult to discover on purpose (and confusingly easy to discover on accident when you get weird errors as SQLite tries in vain to execute some invalid SQL fragment you accidentally had selected before you hit the run button).

sgbeal 4y ago
> If you consider the design space, “resetting the state every time” is exactly how basically every other “fiddle” app works. This app's design space is exposing the sqlite3 shell app via the web, not to emulate every other fiddle environment. sqlite shell app's doesn't (with very good reason) behave that way and the fiddle frontend is just passing state between the user and that app. > The idea is to let you build up a reproducible, shareable outcome. Because this app has no server-side state, we have no way of _sharing_ the outcome. Large fiddle sites give you a short URL which refers to state in their server-side storage. This app completely lacks that (and we're definitely not going to add server-side state to this app). What we _might_ eventually do is offer the ability to base64-encode the SQL into a URL argument which can be shared, but URL length limits are very server-dependent so it would be impossible to portably share "large" fiddles that way. > (and confusingly easy to discover on accident when you get weird errors as SQLite tries in vain to execute some invalid SQL fragment you accidentally had selected before you hit the run button). There's a comment in the initial example SQL explaining that feature, so it'll _hopefully_ be noticed by people new to the app. (Noting that that's not, as of this writing, yet deployed on the production server.) Another feature under consideration is having it intermittently spit out random tips/reminders to the output area (when the db is not working - the app knows when that's happening), and the exec-selection feature would be one such tip.
- infogulch 4y ago
  "sharing the outcome" in fiddle apps often just means reproducing the input text expecting a reproducible output given consistent input, nothing more. This can be seen through the fact that sometimes the share feature doesn't use any server side storage (link shortener) at all and instead stores the entire text of the fiddle in the url itself, e.g. https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&code=fn%20main()%20%7B%0A%20%20%20%20println!(%22Hello%2C%20sqlite!%22)%3B%0A%7D https://play.rust-lang.org/?version=stable&mode=debug&editio... This is just to clarify GP's perspective, I understand that you may be going more for "instant local sqlite repl environment" than "playground to develop shareable snippets of sqlite commands".
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 ago
  Yeah, 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.

sgbeal 4y ago

> If you consider the design space, “resetting the state every time” is exactly how basically every other “fiddle” app works. This app's design space is exposing the sqlite3 shell app via the web, not to emulate every other fiddle environment. sqlite shell app's doesn't (with very good reason) behave that way and the fiddle frontend is just passing state between the user and that app. > The idea is to let you build up a reproducible, shareable outcome. Because this app has no server-side state, we have no way of _sharing_ the outcome. Large fiddle sites give you a short URL which refers to state in their server-side storage. This app completely lacks that (and we're definitely not going to add server-side state to this app). What we _might_ eventually do is offer the ability to base64-encode the SQL into a URL argument which can be shared, but URL length limits are very server-dependent so it would be impossible to portably share "large" fiddles that way. > (and confusingly easy to discover on accident when you get weird errors as SQLite tries in vain to execute some invalid SQL fragment you accidentally had selected before you hit the run button). There's a comment in the initial example SQL explaining that feature, so it'll _hopefully_ be noticed by people new to the app. (Noting that that's not, as of this writing, yet deployed on the production server.) Another feature under consideration is having it intermittently spit out random tips/reminders to the output area (when the db is not working - the app knows when that's happening), and the exec-selection feature would be one such tip.

infogulch 4y ago
"sharing the outcome" in fiddle apps often just means reproducing the input text expecting a reproducible output given consistent input, nothing more. This can be seen through the fact that sometimes the share feature doesn't use any server side storage (link shortener) at all and instead stores the entire text of the fiddle in the url itself, e.g. https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&code=fn%20main()%20%7B%0A%20%20%20%20println!(%22Hello%2C%20sqlite!%22)%3B%0A%7D https://play.rust-lang.org/?version=stable&mode=debug&editio... This is just to clarify GP's perspective, I understand that you may be going more for "instant local sqlite repl environment" than "playground to develop shareable snippets of sqlite commands".

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 ago
Yeah, 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.