On Mon, Sep 15, 2014 at 1:59 PM, Simon Slavin <slav...@bigfraud.org> wrote:
> On 15 Sep 2014, at 12:19pm, Dominique Devienne <ddevie...@gmail.com> > wrote: > > On Mon, Sep 15, 2014 at 12:29 PM, Dan Kennedy <danielk1...@gmail.com> > wrote: > >> On 09/15/2014 03:18 PM, Dominique Devienne wrote: > >>> want to update a single byte of a blob, you must rewrite the whole row, > >>> i.e. the whole blob(s) in that row (and I think this applies to any > column > >>> of the row, not only blob columns). This is just prohibitive, and > >>> unmanageable in practice. > >> > >> I think the only exception to this is if you use the incremental-blob > API: > >> > >> http://www.sqlite.org/c3ref/blob_open.html > > > > What do you mean Dan? Are you saying that opening an existing blob, > writing > > 1 byte somewhere, and closing it, does not yield the whole row to be > > updated? > > Correct. That's what the incremental-blob API does. It just rewrites > bytes wherever the existing row is on disk, Then how is this transaction safe? I might not be reading the doc right, but I don't see it saying that the incremental bob APIs are not transaction safe. > [...] and you can't use it to change the length of the BLOB. > And there lies the rub... Just like SQLite might need to "allocate" a new page for the "inner" SQLite DB within an "outer" blob value, thus extending the "file" / blob, so does those libraries I'm talking about. In any case, I appreciate the details, even though they raise as many questions in mind as they answer, obviously. --DD _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
