I really like the VS Code extension for sqliteview.app - [0]. It also offers an edit feature for a reasonable price, in my opinion. I'm curious if there are any competing editor alternatives. [0] - https://vscode.sqliteviewer.app/
The only reasonable price for editing a SQLite database is $0.
Or $2000 for a perpetual license to the Sqlite Encryption Extension, if the database is encrypted ;)
Honestly not a bad price if you're building it into a real product. Steep for hobbyists though.
This really would've come in handy when I was debugging my own SQLite parser a couple weeks ago.
One thing that initially confused me was how exactly the pages worked w.r.t. the first page on disk... I misunderstood the SQLite documentation in different ways, but it's really rather simple: the very first page is just treated as containing the file header in it, and it pushes down the rest of the data, making the page shorter than the other pages. You can see that illustrated clearly if you click into the first page of a database using this tool: the database header comes first, then the page header.
This tool will undoubtedly come in handy for anyone who has a reason to be dealing with SQLite data structures directly for whatever reason, especially since the SQLite documentation is a bit terse at times.
Really nice, looks great! However, I am not a fan of uploading databases to "strange" sites on the internet, so I will probably never use this.
AFAICT it's purely frontend, there is no uploading. Aside from running it yourself, another thing you can do is go into devtools and set the network throttling to "offline". (Note that this is not fool-proof, but it does prevent new connections from being established.)
Really nice, looks great! However, I am not a fan of uploading databases to "strange" sites on the internet, so I will probably never use this.
It's hard to know whether anything is actually uploaded, but thankfully SQLite databases are plentiful that don't contain sensitive data (and this, also, is why there is a sample database included).
This really would've come in handy when I was debugging my own SQLite parser a couple weeks ago. One thing that initially confused me was how exactly the pages worked w.r.t. the first page on disk... I misunderstood the SQLite documentation in different ways, but it's really rather simple: the very first page is just treated as containing the file header in it, and it pushes down the rest of the data, making the page…
I really want a data format that is effectively binary JSON. What is the subset of all of the features of SQLite that makes either a read-only or an updatable data set that is compact. But better searchability than a streaming parser.
This really would've come in handy when I was debugging my own SQLite parser a couple weeks ago. One thing that initially confused me was how exactly the pages worked w.r.t. the first page on disk... I misunderstood the SQLite documentation in different ways, but it's really rather simple: the very first page is just treated as containing the file header in it, and it pushes down the rest of the data, making the page…
I really want a data format that is effectively binary JSON. What is the subset of all of the features of SQLite that makes either a read-only or an updatable data set that is compact. But better searchability than a streaming parser.
If you want to maintain the properties that SQLite has for read use cases, you'll need to replicate a couple of features. At the very least, you'll probably want the format to still be page-based with a BTree structure. You really could get away with just using the SQLite format if you didn't mind the weirdness; a functional SQLite parser that can read tables would not be a significant amount of code. I think, though, that if you want to read the schema as SQLite understands it, you'd need to interpret the CREATE TABLE syntax, which would make it a bit more complex for sure. Otherwise, you can read tables and columns themselves relatively easily, and the values are all stringified.