3 ms·
I almost do this. My main APIs are POST/GET sqlite databases (ie: I build a sqlite db and return it like a file, then in clients and use it. Not using stupid JS
by mamcx 9y ago
I almost do this. My main APIs are POST/GET sqlite databases (ie: I build a sqlite db and return it like a file, then in clients and use it. Not using stupid JSON when I need long rows!).
--
I'm dreaming about building a relational language and by the way build a RDBMS on top of maybe sqlite. I think exist a lot of potential for a relational store with more flexibility
Think: with both in-memory and on-disk data storage, fixed schema (as normal) + dynamic (like JSON) + Flexible.
By flexible I mean to use Union Types and return mixed rows:
//A union of several schemas:
Table Log =
| Customer
| Order
| OrderLine
SELECT Log =
Customer(1,...).
Customer(2,...)
Order(1, ...)
OrderLine(1, ...)
Also, maybe allow to directly acces indexes (so a index is just a KV store!), to allow logical log manipulation, etc.
In short, what about a relational-redis?
- dfox 9y agoTransferring whole sqlite databases makes sense when one side (usually the client) really uses the file as semi-persistent database for some non-trivial timespan (we actually do that for most of our mobile applications, usually for long-lived read only reference data, but one of our applications actually POSTs modified sqlite files back to server as part of normal operation, which is in fact mainly a hackish way to overcome memory limitations of the hardware involved). Using it only as data format for the transfer is hugely inefficient in terms of both time and bandwidth.
- mamcx 9y agoYes. That is why a better options is to have a kind of streamable relational format (a JSON for tables ?). The problem is that using sqlite it also embed a functional query engine, when a simple data format requiere extra layers to make it work. So even better is to have a sqlite-like engine that allow partial/streamable reading/writes.