[HN Gopher] Replacing Complicated Hashmaps with SQLite
___________________________________________________________________
Replacing Complicated Hashmaps with SQLite
Author : wilsonehusin
Score : 27 points
Date : 2024-04-06 08:44 UTC (14 hours ago)
(HTM) web link (husin.dev)
(TXT) w3m dump (husin.dev)
| chrisaycock wrote:
| The post isn't specific to needing SQLite. Rather it's about the
| convenience of expressing an algorithm as a query and then using
| SQLite to execute the query.
|
| I agree; queries are why table semantics are so useful. Whether
| you choose an SQL implementation (e.g., DuckDB and SQLite) or a
| dataframe library (e.g., pandas and polars), expressing searches,
| joins, and aggregations becomes trivial for tabular data.
| imiric wrote:
| SQLite is great. I've also recently settled on it as a key-value
| store, after considering a few purpose-built key-value solutions.
| Turns out that it's really easy to make SQLite work as a key-
| value store, but very difficult to make key-value stores
| relational, if you ever need to.
|
| Just be careful with `:memory:` databases. From the mattn/go-
| sqlite3 FAQ[1]:
|
| > Each connection to ":memory:" opens a brand new in-memory sql
| database, so if the stdlib's sql engine happens to open another
| connection and you've only specified ":memory:", that connection
| will see a brand new database. A workaround is to use
| "file::memory:?cache=shared" (or
| "file:foobar?mode=memory&cache=shared"). Every connection to this
| string will point to the same in-memory database.
|
| I noticed strange behaviors with just `:memory:` where tables
| would disappear at random, and this workaround helped. Make sure
| to use a unique filename as the `file:` value, especially if
| using this in tests.
|
| [1]: https://github.com/mattn/go-sqlite3#faq
___________________________________________________________________
(page generated 2024-04-06 23:01 UTC)