SQLite Blob读写的局限性

在使用SQLite在Windows Mobile上的大容量BLOB读写时，遇到一个OOM(Out Of Memory)的问题，让我们都觉得不可思议： 

试看下边的SQL语句代码片段：

    executeStmt(db, stmt, "create table foo(id integer not null primary key, content blob null, content2 blob null)"); 
    
    sqlite3_stmt* stmt2 = NULL; 
    executeStmt(db, stmt, "insert into foo(id) values(10)"); 

    sqlite3_stmt* stmt3 = NULL; 
    executeStmt(db, stmt3, "update foo set content=zeroblob(10*1024*1024) where rowid=10"); 

    sqlite3_stmt* stmt4 = NULL; 
    executeStmt(db, stmt4, "update foo set content2=zeroblob(1024) where rowid=10"); // OOM here  
    不过是单个数据库列的0填充而已，怎么会出现OOM呢？ 

我直接给它的作者Dr. Richard Hipp和他的team发邮件询问，得到的答复是： 
每次更新，sqlite都会读取该行的数据，加载到内存里。难怪，第一列可是要10M内存。 
Richard建议：使用incremental BLOB I/O mechanism机制进行读写。 
可是这个机制局限性依然明显： 
e.g. 
first write,  20K, then append 10K.  If we want to append it,  we need to zeroblob 30K first. Otherwise, sqlite_blob_write will fail to write the chunk. 
??? 
他的答复是： 
Unfortunately, no; there is no way to increase the size of a row without allocating memory sufficient to hold the entire row. 
除非要更改sqlite的文件格式。一旦更改，将会打破与以前sqlite文件的兼容性。那是不可容忍的。 

看来，使用小内存逐步分片更改blob字段，在目前来看无法实现。只能接受此现实。