The compatibility information at http://sqlite.org/formatchng.html states that on disk file formats can change (albeit rarely) between major versions (first digit of version number).
"When this happens and you must convert the contents of your databases into a portable ASCII representation using the old version of the library then reload the data using the new version of the library." In the future I assume we will want to update the version of SQLite shipped with Solaris? If there is an on disk format change all users will need to migrate their databases, which requires both the old & new versions of the library to be available. I don't see any mention or consideration for this in the case notes. That said, it seems that maybe all the path & package names in the interface table are suffixed (or include) with the major version. Is that right? When you integrate SQLite version 4.x will it be shipped in package SUNWsqlite4, and will the library be called /usr/lib/libsqlite4.so? If so, then it's possible the product is already future proof wrt. multiple major versions? If there's any name clashes between files from different versions, then you need to consider locating them somewhere other than /usr/bin, /usr/lib, /usr/include, etc. John Fischer wrote: > LSARC, > > I am sponsoring this fast track for Elaine Xiong from the Mozilla > team in Beijing. I have set the timeout for February 5th, 2008. > The case materials contains this proposal. > > This project introduces SQLite 3.x into a Minor release of Solaris. > The project includes the sqlite3, libraries, pkgconfig, header files > and man page. The project is required by Firefox web browser and > Thunderbird mail client. > > Thanks, > > John > > > ------------------------------------------------------------------------ > > Sun Proprietary/Confidential: Internal Use Only: Engineering Need-to-Know > > 1. Introduction > 1.1. Project/Component Working Name: > > SQLite > > 1.2. Name of Document Author/Supplier: > > Author: Elaine Xiong > Sponsor: John Fischer > > 1.3. Date of This Document: > > 01/14/2008 > > 1.4. Name of Major Document Customer(s)/Consumer(s): > 1.4.1. The PAC or CPT you expect to review your project: Solaris PAC > 1.4.2. The ARC(s) you expect to review your project: LSARC > 1.4.3. The Director/VP who is "Sponsoring" this project: Robert Odea > 1.4.4. The name of your business unit: Software > > 1.5. Email Aliases: > 1.5.1. Responsible Manager: leo.binchy at sun.com > 1.5.2. Responsible Engineer: elaine.xiong at sun.com > 1.5.3. Marketing Manager: jeff.mcmeekin at sun.com > 1.5.4. Interest List: brian.lu at sun.com > > 2. Project Summary > 2.1. Project Description: > > SQLite is a C library that implements a small, fast, embeddable SQL > database engine that supports most of SQL92, including transactions > with atomic commit and rollback, subqueries, compound queries, > triggers, and views. Programs that link with the SQLite library can > have SQLite database access without running a separate RDBMS process. > > 2.2. Risks and Assumptions: > > SQLite is out of the support range of DBTG team only engaged in level > 1 database technology, so we desktop team take responsible of > shipping > SQLite into Solaris. This project only proposes to fix bugs which > affects Firefox3/Thunderbird3. The remainder counts on community > development. > > 3. Business Summary > 3.1. Problem Area: > > SQLite is utilized by Firefox3/Thunderbird3 to do all the storage > which contains history and bookmarks, address books, download > history and site specific preference. > > 3.3. Business Justification: > > The code for SQLite is in the public domain and is thus free for use > for any purpose, commercial or private. > > Of level 2 database technologies for Sun products, SQLite is designed > to be embedded in applications and in hardware. More and More > well-known > projects and companies turn to use SQLite as the in-process RDBMS. > This > project also fills the gap between Linux and Solaris since SQLite is > released in many Linux distributions such as Unbuntu, Debian, and > Fedora. > > 3.6. How will you know when you are done?: > > When it gets integrated into Solaris Neveda builds. > > 4. Technical Description: > > 4.1. Details: > > This project will port SQLite 3.x from the original community to > Solaris. It involves shipping SQLite into Solaris Neveda, bug fixing > regarding Firefox3/Thunderbird3 and performing the minor version > upgrade from community. > > SQLite Features: > > - Transactions are atomic, consistent, isolated, and durable (ACID) > even after system crashes and power failures. > - Zero-configuration: no setup or administration needed. > - Implements most of SQL92. Unsupported features of SQL92 are > shown below. > - FOREIGN KEY constraints > - Complete trigger support > - Complete ALTER TABLE support > - Nested transactions > - RIGHT and FULL OUTER JOIN > - Writing to VIEWs > - GRANT and REVOKE > - A complete database is stored in a single cross-platform disk file. > - Supports terabyte-sized databases and gigabyte-sized strings and > blobs. > - Small code footprint: less than 250KiB fully configured or less > than > 150KiB with optional features omitted. > - Faster than popular client/server database engines for most common > operations. > - Simple, easy to use API. > - Written in ANSI-C. > - Well-commented source code with over 98% test coverage. > - Available as a single ANSI-C source-code file that you can easily > drop > into another project. > - Self-contained: no external dependencies. > - Cross-platform > - Sources are in the public domain. Use for any purpose. > - Comes with a standalone command-line interface (CLI) client that > can > be used to administer SQLite databases. > > 4.5. Interfaces: > > Exported Interfaces > Interface Classification Comments > --------------- --------------- ----------------------- > SQLite3 CLI Volatile > SQLite3 API Volatile > SQL92 features Volatile SQLite3 implements most > of SQL92 and the > unsupported > features might be added in > the future. > /usr/bin/sqlite3 Volatile > /usr/lib/libsqlite3.so Volatile > /usr/lib/libsqlite3.so.0 Volatile > /usr/lib/libsqlite3.so.0.8.6 Volatile > /usr/lib/pkgconfig/sqlite3.pc Volatile > /usr/include/sqlite3.h Volatile > /usr/include/sqlite3ext.h Volatile > /usr/share/man/man1/sqlite3.1 Volatile > SUNWsqlite3 Uncommitted > SUNWsqlite3-devel Uncommitted > > > 4.6. Doc Impact: > > man page for sqlite3(1) > > 4.7. Admin/Config Impact: > > None > > 4.8. HA Impact: > > None > > 4.10. Packaging & Delivery: > > The new packages are: > - SUNWsqlite3 > - SUNWsqlite3-devel > > 4.11. Security Impact: > > SQLite itself as a backend storage is not encrypted or > password-protected by default. Any project that uses SQLite > should be aware of or enhance the security upon the specific > requirement from the project purpose. A SQLite database is > stored as a binary file which access control is performed by > the underlying operating system based on the file's permission > setting. > > 4.12. Dependencies: > > No external dependencies. > > 5. Reference Documents: > SQLite Homepage - http://www.sqlite.org > SQLite Development Page - http://www.sqlite.org/cvstrac/wiki > SQL As Understood By SQLite - http://www.sqlite.org/lang.html > SQLite C Interface - http://www.sqlite.org/c3ref/intro.html
