4 ms·

I played with it for a minute, and the feature I want is just a checkbox to reset the database each time I run the query. It's nice to be able to iteratively b

I played with it for a minute, and the feature I want is just a checkbox to reset the database each time I run the query. It's nice to be able to iteratively build up a sequence of queries on the input, including creating tables, inserting items, etc. But, I don't even see a manual way to clear the database (which maybe should be a button too?) without refreshing the page... and refreshing the page forgets all of my preferences. (it still manages to keep the query input, it looks like, which is a start... but maybe that's just my browser trying to be helpful.)

sgbeal 4y ago
> I played with it for a minute, and the feature I want is a checkbox to reset the database each time I run the query. That's a good idea. There are tons of options i'd _like_ to add to it but have not simply for UI space's sake. The real limit on the UI is "how many options can we fit while still leaving room for input and output." Nobody involved in the development effort is a particularly strong UI developer (i can say that because i'm the one who wrote that UI ;), and assistance in prettying it up and improving the U/X would certainly be appreciated. > But, I don't even see a manual way to clear the database without refreshing the page... and refreshing the page forgets all of my preferences. Storing of the preferences in localStorage is on my TODO list. The underlying mini-API for it is in place, i just haven't yet dedicated the few hours to plug it all in and test it. Baby steps. > (it still manages to keep the query input, it looks like, which is a start... but maybe that's just my browser trying to be helpful.) That it keeps the query input is a _browser-specific quirk_, not an explicit feature. By and large, that quirk (Firefox, right?) is a huge pain in the butt in web development because it forces the developer to do a full reload on each hit, bypassing all caching.
- coder543 4y ago
  > By and large, that quirk (Firefox, right?) Yep, definitely Firefox. In this case, my first thought was that the webpage was "doing the right thing", but then I realized the browser was probably doing it. Either way, it is the behavior I would expect in this case, so I consider that a win, but I understand it can be challenging for web developers under other circumstances. > assistance in prettying it up and improving the U/X would certainly be appreciated. My understanding is that the SQLite team typically isn't very open to outside contribution. UI/UX historically isn't my strong suite either, though, but I have been trying to work on that lately.
  - sgbeal 4y ago
    > Yep, definitely Firefox. In To be clear, i wasn't badmouthing FF (all of fiddle's develoment so far, aside from occasional individual tests) has been in FF on Linux. That one particular FF feature kinda gets my goat, though, when i'm writing web apps ;). > My understanding is that the SQLite team typically isn't very open to outside contribution. It's not the contribution, per se, but actual code patches are tricky for the sqlite project because of licensing. sqlite is released into the public domain by its creators, but not all legal jurisdictions recognize public domain as a real thing. Thus Richard is extra-extra-careful to ensure that all of the code which goes in to the repository is added by someone who's signed a waiver validating that any code they added is not going to be a licensing issue, and only people Richard has come to know and trust are offered the option of signing that waiver. Often, when patches are posted by users, they can be used as a basis for equivalent patches but cannot be used as-is because of the potential for licensing fallout.
sgbeal 4y ago
> I played with it for a minute, and the feature I want is just a checkbox to reset the database each time I run the query. After experimenting, i'm extremely hesitant to add the option to _automatically_ nuke the db each time input is submitted because, frankly, That Way Lies Madness and you are probably the only person who would use it. However, the app now has a button to nuke the db. 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's not yet (as of this writing) deployed but will be the next time Richard updates the site.
- coder543 4y ago
  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.

sgbeal 4y ago

> I played with it for a minute, and the feature I want is a checkbox to reset the database each time I run the query. That's a good idea. There are tons of options i'd _like_ to add to it but have not simply for UI space's sake. The real limit on the UI is "how many options can we fit while still leaving room for input and output." Nobody involved in the development effort is a particularly strong UI developer (i can say that because i'm the one who wrote that UI ;), and assistance in prettying it up and improving the U/X would certainly be appreciated. > But, I don't even see a manual way to clear the database without refreshing the page... and refreshing the page forgets all of my preferences. Storing of the preferences in localStorage is on my TODO list. The underlying mini-API for it is in place, i just haven't yet dedicated the few hours to plug it all in and test it. Baby steps. > (it still manages to keep the query input, it looks like, which is a start... but maybe that's just my browser trying to be helpful.) That it keeps the query input is a _browser-specific quirk_, not an explicit feature. By and large, that quirk (Firefox, right?) is a huge pain in the butt in web development because it forces the developer to do a full reload on each hit, bypassing all caching.

coder543 4y ago
> By and large, that quirk (Firefox, right?) Yep, definitely Firefox. In this case, my first thought was that the webpage was "doing the right thing", but then I realized the browser was probably doing it. Either way, it is the behavior I would expect in this case, so I consider that a win, but I understand it can be challenging for web developers under other circumstances. > assistance in prettying it up and improving the U/X would certainly be appreciated. My understanding is that the SQLite team typically isn't very open to outside contribution. UI/UX historically isn't my strong suite either, though, but I have been trying to work on that lately.
- sgbeal 4y ago
  > Yep, definitely Firefox. In To be clear, i wasn't badmouthing FF (all of fiddle's develoment so far, aside from occasional individual tests) has been in FF on Linux. That one particular FF feature kinda gets my goat, though, when i'm writing web apps ;). > My understanding is that the SQLite team typically isn't very open to outside contribution. It's not the contribution, per se, but actual code patches are tricky for the sqlite project because of licensing. sqlite is released into the public domain by its creators, but not all legal jurisdictions recognize public domain as a real thing. Thus Richard is extra-extra-careful to ensure that all of the code which goes in to the repository is added by someone who's signed a waiver validating that any code they added is not going to be a licensing issue, and only people Richard has come to know and trust are offered the option of signing that waiver. Often, when patches are posted by users, they can be used as a basis for equivalent patches but cannot be used as-is because of the potential for licensing fallout.

sgbeal 4y ago

> I played with it for a minute, and the feature I want is just a checkbox to reset the database each time I run the query. After experimenting, i'm extremely hesitant to add the option to _automatically_ nuke the db each time input is submitted because, frankly, That Way Lies Madness and you are probably the only person who would use it. However, the app now has a button to nuke the db. 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's not yet (as of this writing) deployed but will be the next time Richard updates the site.

coder543 4y ago
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.