Quoth Richard Hipp <d...@sqlite.org>, on 2013-05-03 14:00:28 -0400: > The release of SQLite 3.7.17 has been tentatively scheduled for > 2013-05-22. We do not anticipate any further application-visible changes, > though we may well merge the winOsTrace branch ( > http://www.sqlite.org/src/timeline?r=winOsTrace) prior to release. A > summary of changes can be seen here: > > http://www.sqlite.org/draft/releaselog/3_7_17.html
I (predictably) approve of the following: - adding support for memory-mapped I/O but requiring explicit enable - secondary application ID support - the detection of file link mismanagement on Unixy systems - extension loading more compatible with C flat-namespace behavior I have not actively tested the latest snapshots yet. It would be useful to clarify the error behavior in the document on memory-mapped I/O. Currently, it reads: "Instead, the I/O error causes a signal which, if not caught by the application, results in a program crash." This could be read to imply that it is safe for the application to catch the signal and longjmp away to abort the operation. The documentation should explicitly say what states the SQLite data structures may be in in such a case. If this has not already been considered, the answer could be presumed to be that they may be in an inconsistent state and should not be further touched at all. Minor question: why is the application ID four octets rather than the eight that were originally suggested? It would also be convenient for the application_id pragma to be able to use strings or integers; I might split it into application_id_integer and application_id_string to minimize confusion over return values. But this is not essential. Do you accept "speculative" application ID registrations to avoid software that might or might not later be published potentially taking a sudden change of ID? Do you accept "two-level" registrations that would use the "application ID" as more of a "vendor ID" and the user_version as a per-vendor application+schema-version ID? ---> Drake Wilson _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
