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

Reply via email to