Different use-cases may employ different strategies. For example, emailing falls back to non-sensical values for development, while constructing back-redirection links for OAuth has a hard dependency on site_url. The latter requires editing the config anyway so it certainly seems reasonable to ask users to also sepecify a url even if it's just "http:localhost:4000".
All the admin operations do not properly qualify tables, views... . To
be generally useful, this is also missigng schema-handling for multiple
dbs.
We could just rely on migration files fully qualifying, however this
wouldn't work well with db renames. We also don't want to store
migration state for "test.db" in "main.db".
Note that this complicates the APIs, since it pushes the responsibility
of declaring a query a read or write to the user to then be scheduled
appropriately.
Add `.(read_|)query_row_f` APIs similar to rusqlites
`conn.query_row` accepting a `|row| -> Result<T>` to reduce the use of
`Row` and `Rows`.
Make benchmarks more isolated by not sharing a DB across runs
accumulating writes.
There's a couple of reasons:
* As for the rust bindings: they're sub-par to rusqlite, though
rusqlite is amazing. Even libsql-server uses rusqlite over their own
bindings. The bindings are missing features such as update hooks
and the hard-coded execution model suffers from lock congestion.
* We've fixed bugs (e.g. trivial null ptr accesses went unnoticed),
raised issues, and tried to add missing functionality such as update
hooks. It's unclear if the rust-bindings are a priority or covered by
the principles laid out in the libsql manifesto. From the outside it
looks like focus has shifted to https://github.com/penberg/limbo.
* As for the C-libsql fork for SQLite itself, it's getting more and
more outdated (2024-01-30 (3.45.1)) and it's unclear when and if the
ideas from the manifesto will manifest.
Looking forward this opens the door for TrailBase to:
* Bundle more recent versions of SQLite
* Implement more performant, better scaling execution models.
* Implement realtime APIs for subscribing to data changes.
After spending too much time researching licenses, my laymen
understanding makes me feel that OSL-3.0 will be a better match given
TrailBase's rare dual use as a standalone backend or framework.
It tried to outline the reasoning in the README.md. I would appreciate
input from anyone more experienced with licenses.
For now, I would like to turn my attention back to more technical issues
:hide:.
Sebastian Jeltsch