Sql.js is awesome. It powers sqlteaching.com (on the client side), and the whole site took about 50 hours of work between my wife and I. Most of that time was on the curriculum.
I circulated this through my workplace (cca 900 people). We've got a lot of mostly-non-tech people (testers and analysts) who have some interaction with our product via SQL where reports or UI aren't available. They usually create simple SELECT queries, or re-use more complex prewritten ones. I think many people will use this to get a better understanding of how everything they're using fits together.
I've no doubt it will be a hit, thank you very much for taking the time to create this.
nice site, I'm going to share it with my friends and family who might be interested in learning about databases but not technically savvy enough to setup and admin an entire server by themselves...
Unfortunately, there are a few major downsides to sql.js:
1. Not API compatible with node-sqlite3, so you can't just drop it in and use it with knex or other wrappers.
2. Doesn't support in-place editing of a db. You have to load the entire DB into memory, modify it, and then save it back, making it unsuitable for any concurrent application.
I love the idea of the project though, and it would be awesome not to have to deal with compiling sqlite or using node-pregyp to build embedded chromium apps.
I think the whole point is that it runs in a browser, where you can't install sqlite otherwise. If you're running node, you can almost certainly run a native binary of sqlite.
All good points, but I think the primary use case (in a browser) doesn't experience these downsides nearly as much (JS is single threaded in the browser so concurrent access is not a big deal). It would be nice to use knex with it though..
Build a VFS layer that uses something like https://code.google.com/p/limbo-machine/wiki/JS to talk over a websocket or http message proxy to a file store and you get in-place editing. It will probably be hell for the 'usual' usecase of nonconcurrent in-page use however. Also, LOL locking, which is the real utility of SQLite's VFS layer.
Not OP, but I imagine it's a couple things:
1) No clear mapping between file APIs that SQLite uses and browser file APIs.
2) SQLite uses blocking file I/O internally which is generally a big no-no for JavaScript due to it being single threaded.
SQLite is proably saving files in emscripten's virtual filesystem (emscripten's implementation of fopen() etc. by default makes them work on memory), and the sql.js API just reads and writes the file there.
What I would love to see is a SQLite rewrite in Rust. Just enough to support WebSQL and appease Mozilla's concern about the lack of alternative implementations.
I thought the issue with SQL as a web standard period was it's under specified. So, rather than put SQL in the browser and then run into all kinds of incompatible edge cases they went with something simpler and easier to define and get right. You can then make your own library (SQL if you prefer) and be more likely to get the exact behavior you want across browsers.
"What I would love to see is a $PROJ rewrite in Rust." has kinda become a mantra of mine, particularly for things like SQLite which are core dependencies of so many other things.
The problem is that it isn't so much about an interface-compatible version of $project in Rust - the value of things like SQLite is in the huge amount of testing and perf work that's been done over the years. You could do a toy reimplementation, but the value wouldn't be there.
Luckily a huge amount of that testing work has been captured in a comprehensive test suite for SQLite that any alternative implementation could easily use to ensure compatibility.
Yeah, let's rewrite $PROJ in a language few people use, with a lacking toolchain, and that few people will be bothered to use said rewrite, since it will make their life difficult to connect to it (they'd need a Rust toolchain to compile it for one).
"Few people will use a Rust library because they'd need a Rust compiler" doesn't make sense to me, because odds are good that the Rust compiler can target the platform you used to post this comment.
SQLite is rather heavily used in the embedded world, which uses a lot of architectures that llvm hasn't been ported to. Hitachi's SH, NEC's v850, etc are all targets people pay the sqlite maintainers for test suites, porting, etc. A rewrite in rust would eliminate a lot of income the developers of sqlite count on, because the toolchain just doesn't have the breadth of targets that c does.
"Nobody should bother developing an alternative to SQLite because 1% of SQLite's users won't be able to run it" isn't a valid argument against developing an alternative any more than "Microsoft shouldn't bother developing Windows 95 because some users still have a 286" would have been in 1993.
Nobody is saying that those who need SQLite as it exists today shouldn't continue to fund its development. It's just that writing off the development of alternatives as unrealistic because they'll only be runnable by 99% of SQLite's install base as opposed to 100% of it is silly.
Kind of ridiculous that someone downvoted this. Aren't downvotes supposed to suggest that the comment detracted from the conversation? In what way am I detracting from the discussion? Disagreeing isn't a reason to downvote.
Ignore individual downvotes. They're often mistakes, or people in bad moods, or etc. They usually get corrected, although as you've seen not enough people provide corrective upvotes.
Downvote for disagreement has a bit of history on HN.
I'm not implying anything about what SQLite's development priorities should be. I'm arguing against the idea that developing a SQLite alternative in Rust is infeasible for portability reasons.
>"Nobody should bother developing an alternative to SQLite because 1% of SQLite's users won't be able to run it"
...and a 80% or more of the rest 99% wont bother to run it, because all it buys them is hassle, as SQLite is present everywhere, well maintained by the guy who wrote it, with lots of books on it, interfaces for all their favorites languages and environments, tested thoroughly by its dev, and battle proven.
Of course somebody can write it in Rust, and do whatever they like. It might even catch on eventually.
But merely "it will be more secure because of advanced compiler technology" is not that enticing an argument -- especially if people don't have many security issues with it in the first place.
At this point you're arguing against a lot of things I've never said. Obviously an alternative to SQLite will have to be compelling enough to motivate its use in ways that likely exceed just memory safety concerns. That is true of any proposed replacement for any piece of software. The point is simply that, if you want to write a SQLite alternative, Rust is a reasonable language to write it in.
>At this point you're arguing against a lot of things I've never said.
Yeah, didn't say you said those.
But since I started this subthread, I'm merely expanding and explaining further the thigs I said initially.
>The point is simply that, if you want to write a SQLite alternative, Rust is a reasonable language to write it in.
Oh, on that I agree.
I was mainly questioning the need to rewrite in the first place (and especially for this particular software, being an embedded db et al), not whether Rust as a language is a good choice to do so.
That said, the less mature ecosystem/toolchain etc, is still an issue for some projects that would still benefit from Rust -- e.g. for somebody used to work with VS C++, etc.
For one, you're still making breaking changes to it. Then there's issues like a full blown debugger, the compiler is slow, etc. Maturity. I'm not even going into IDE terittory which Windows guys will want.
SQLite is used in tons of software. Why add a Rust compiler dependency on its build stage, if SQLite already serves them well and they already work in C/C++ land for the rest of the code of their project?
Rust isn't making breaking changes anymore. I think people are getting hung up on "theoretically breaking" changes that don't break anybody in practice and are equivalent to the "theoretically breaking" changes that C and C++ (and every other actively developed language) continue to make all the time.
> SQLite is used in tons of software. Why add a Rust compiler dependency on its build stage, if SQLite already serves them well and they already work in C/C++ land for the rest of the code of their project?
Because a replacement might have more features/better performance/improved security? These are the same reasons you might look for alternatives for any piece of software!
>Rust isn't making breaking changes anymore. I think people are getting hung up on "theoretically breaking" changes that don't break anybody in practice and are equivalent to the "theoretically breaking" changes that C and C++ (and every other actively developed language) continue to make all the time.
That's good to know. In the language OK, not even in the standard lib?
>Because a replacement might have more features/better performance/improved security? These are the same reasons you might look for alternatives for any piece of software!
Most of that (more features, better performance) are orthogonal to Rust. Features obviously (if anything a port will probably have even LESS features initially, as Sqlite got most of its features piecemeal too).
And how is better speed assured with the Rust rewrite considering that Sqlite is pretty fast C already?
At best it might be the same speed (and if it's an algorithmic issue that slows down Sqlite, then of course they can also fix their C code and overcome that).
Which leaves us with "better security". Is it compelling enough to change software? Depends, I say.
Did someone try to compile Zebra Crossing (ZXing) to JavaScript using Emscripten? I searched a lot, but sadly didn't find anyone who succeeded. And I don't have enough knowledge about C++ to try it myself.
The C++ version of ZXing is no longer maintained. Unless you really need everything clientside, I'd just go wrap the Java library in a RPC like Thrift and bolt it in to your backend.
Wow, really amazed with your app!! My catalog is 500Mo and was analysed super fast! Love the filters too and the ability to restrict the period (it would be even nicer if we could move some sliders to analyse a specific period). Anyway, this is totally amazing! ;-)
---
Now this is really, completely OT, but since you seem to be an expert with Lightroom catalogs, I wonder if you would know the answer to the following problem.
I had been using Lightroom 3 for a very long time, with newer cameras the RAWs of which it couldn't read, so I converted the RAW files to DNG using the Adobe utility. This was fine but used double disk space.
Now I finally upgraded Lightroom; I still have the original RAW files and was wondering if I could somehow replace the pointers to the DNGs with the original RAWs in the .lrcat catalog file; would that work, or completely break everything? (The point being, to get rid of the DNG files on disk).
I wonder how well this would work for shipping game assets in the browser. One of the nice things I miss about flash was having a single compiled object to store on the server and distribute to end users which contained all the assets and sounds needed for the game. Stuffing all your assets into a sqlite database and sending that over the wire would keep everything nice and tidy.
SQLite does mean you'll have overhead in retrieving that data, though. If you want to be able to do SQL queries on it, it's worth it, but otherwise it's probably not.
If you just want a single file, you can bundle all the assets into one and emit some metadata so you know where each file starts and ends. Emscripten's file packager does this, for example.
