On 4/15/18, dave <d...@ziggurat29.com> wrote: > I had a stray thought, and wanted to ask if it's been thunk before,and if so > what is the thinking? Or just for commentary. > > I have been building a system, part of which uses sqlite and virtual tables. > This is working great in a desktop/mobile environment. However, eventually > one day, I will want to migrate aspects of the product to deeply embedded > systems (e.g. something like an STM32F4 class chip), and am thinking about > size -- both code and RAM. I know about the various compile switches that > can turn off various features, but I wonder if I can really strip it down > further by eliminating parsing, query planning, etc, altogether, and only > support the virtual machine. I do need virtual tables, though. In my > particular use-case, I only need read access -- no create or update. The > thinking being that I can build queries offline and compile them into the > p-code (or whatever it's called), and either burn those well know queries > into flash, or perhaps send them down the wire as needed. Then of course > (maybe even more critically), can I control ram usage in a deterministic way > such that it will still work on memory-constrained devices (e.g. having a > total of 128 KiB max for the whole system). > > Anway, has this been discussed before? Or is it a fool's errand?
We did this once, back in 2005, for a startup company in Boston. It was called "SSE". Unfortunately, we didn't continue to support it. I went looking for the source code and could not find it. The database was to run on a smart-card with limited RAM. All of the prepared statements were generated on a workstation, then serialized and stored in a special table in the database file. The application would then use a special API that would deserialize a prepared statement (identified by a well-known integer) then bind parameters and run it. So much has changed in the SQLite bytecode engine since then that there is basically zero chance that SSE would still run today, even if I could find the source code. -- D. Richard Hipp d...@sqlite.org _______________________________________________ sqlite-users mailing list sqlite-users@mailinglists.sqlite.org http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
