3 ms·

I’m an absolute fanboy of all the efforts to bolt on SQL interfaces to things. I love this. Kudos to the creator.

eitland 6y ago
You are maybe aware of this already then but someone here might like to know that the Fossil DVCS is built on top of SQLite, by the same author (edit as pointed out by Gaelan:) as SQLite.
- Gaelan 6y ago
  To be clear, the same author as SQLite, not Askgit.
  - gigatexal 6y ago
    I did not know that. Thank you!
  - eitland 6y ago
    Thanks for pointing out, I thought it was obvious from the context but I'm glad someone tells me when it is not.
cube2222 6y ago
If you like this, check out OctoSQL[0], it bolts on SQL on json, CSV, Excel and Parquet files. It also let's you join them with each other (and other databases). [0]:https://github.com/cube2222/octosql https://github.com/cube2222/octosql
- sirodoht 6y ago
  There is also xsv [0] for CSV SQLing [0] https://github.com/BurntSushi/xsv https://github.com/BurntSushi/xsv
  - gigatexal 6y ago
    For this and the above +1 to you both and thanks.
tyingq 6y ago
Sqlite has an api for "virtual tables" that provides a fairly easy way to bolt SQL on top of things. https://www.sqlite.org/vtab.html https://www.sqlite.org/vtab.html I haven't used it directly, but I did use a Perl module that hooks into it, and that made it very easy to cobble together. https://metacpan.org/pod/release/SALVA/SQLite-VirtualTable-0.06/lib/SQLite/VirtualTable.pm https://metacpan.org/pod/release/SALVA/SQLite-VirtualTable-0...
- thechao 6y ago
  The VTAB extension is new. The documentation is a bit thin compared to the rest of SQLite. (To be clear: the documentation is good; just not fantastically awesome like the rest of SQLite.) The main Achille's Heel of VTAB is wrapping your head around the indexing API: the basic idea is you need to tell the query planner which of a set of columns is best to work with. It is exceedingly unintuitive. This is compounded by the problem that the planner essentially refuses to do binary-search queries on more than one column of a VTAB. (Hell -- getting it to use any binary-search on any index is nearly impossible.) The result is that unless you're in a real bind, you should always translate your custom VTAB data into a reified table. This is all compounded by the fact that the slightest misstep in the callback API will corrupt/confuse/lockup SQLite (the in-memory representation -- your data is still safe). I'm glad VTAB exists, and I know it's just a side-effect of the compression support, but goddamn it's frustrating for it to be almost be awesome...
  - gigatexal 6y ago
    Bummer. Perhaps over time these pain points will be remedied.

You are maybe aware of this already then but someone here might like to know that the Fossil DVCS is built on top of SQLite, by the same author (edit as pointed out by Gaelan:) as SQLite.

Gaelan 6y ago
To be clear, the same author as SQLite, not Askgit.
- gigatexal 6y ago
  I did not know that. Thank you!
- eitland 6y ago
  Thanks for pointing out, I thought it was obvious from the context but I'm glad someone tells me when it is not.

cube2222 6y ago

If you like this, check out OctoSQL[0], it bolts on SQL on json, CSV, Excel and Parquet files. It also let's you join them with each other (and other databases). [0]:https://github.com/cube2222/octosql https://github.com/cube2222/octosql

sirodoht 6y ago
There is also xsv [0] for CSV SQLing [0] https://github.com/BurntSushi/xsv https://github.com/BurntSushi/xsv
- gigatexal 6y ago
  For this and the above +1 to you both and thanks.

tyingq 6y ago

Sqlite has an api for "virtual tables" that provides a fairly easy way to bolt SQL on top of things. https://www.sqlite.org/vtab.html https://www.sqlite.org/vtab.html I haven't used it directly, but I did use a Perl module that hooks into it, and that made it very easy to cobble together. https://metacpan.org/pod/release/SALVA/SQLite-VirtualTable-0.06/lib/SQLite/VirtualTable.pm https://metacpan.org/pod/release/SALVA/SQLite-VirtualTable-0...

thechao 6y ago
The VTAB extension is new. The documentation is a bit thin compared to the rest of SQLite. (To be clear: the documentation is good; just not fantastically awesome like the rest of SQLite.) The main Achille's Heel of VTAB is wrapping your head around the indexing API: the basic idea is you need to tell the query planner which of a set of columns is best to work with. It is exceedingly unintuitive. This is compounded by the problem that the planner essentially refuses to do binary-search queries on more than one column of a VTAB. (Hell -- getting it to use any binary-search on any index is nearly impossible.) The result is that unless you're in a real bind, you should always translate your custom VTAB data into a reified table. This is all compounded by the fact that the slightest misstep in the callback API will corrupt/confuse/lockup SQLite (the in-memory representation -- your data is still safe). I'm glad VTAB exists, and I know it's just a side-effect of the compression support, but goddamn it's frustrating for it to be almost be awesome...
- gigatexal 6y ago
  Bummer. Perhaps over time these pain points will be remedied.