On 3/18/18, Olivier Mascia <o...@integral.be> wrote: > Hello, > > What are use cases for these sqlite3_serialize / deserialize? > I understand what they do, from the documentation. > Though I'd like to understand what typically they were introduced for? > (Always trying to learn something here). :)
These APIs support the concept of using small databases (small enough to fit in memory) as a container for passing information around. For example: A client program might communicate with a server using an HTTP request and sending an SQLite database as the POST data. Or the server might send an SQLite database as the reply. If I had had good sense, I might have designed Fossil to do this for the "sync" and "clone" commands, rather than the elaborate protocol (https://www.fossil-scm.org/fossil/doc/trunk/www/sync.wiki) it currently uses. Git does send a database for sync and clone, though it is a bespoke "pack-file" key/value database, not an SQLite database, and that is one aspect of Git that I think is superior to Fossil. Advantages of using an SQLite database as a container: (1) It is easy to mix text and binary data without having to worry with encodings. (2) Applications can be easily enhanced and extended in backwards-compatible ways by adding new columns and/or tables. (3) Easy to manually view or modify the container content during testing and debugging. (JSON also has this property, but JSON does not work with binary data.) (4) No need to write encoder/decoder logic. (5) There is a high-level query language available to extract the content in an order that might be very different from the order it appears in the file. (6) No need to worry with big-endian vs. little-endian translation, nor UTF8 vs UTF16. The database handles that automatically. The first use-case for sqlite3_deserialize() was in the "sessionfuzz" test program which we use together with AFL to fuzz-test the changeset objects associated with the session extension. The original "sessionfuzz" accepted one or more command-line arguments where each argument was a file containing a single changeset. But, we also now allow any of the arguments to be an SQLite database file containing many separate changesets. (An example of such a database is in the test/sessionfuzz-data1.db file in the repository.) The sessionfuzz program reads each file named on the command-line into memory. Then it checks to see if the file begins with "SQLite format 3". If it does, that means the file is an SQLite database and it is processed accordingly. If not, it assumes the file is a corrupted changeset that is a fuzzer input. The sqlite3_deserialize() interface streamlines the decoding process in cases where the chunk of memory containing the file does begin with "SQLite format 3". -- 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
