SQLite Forum

Incremental Blob I/O and virtual tables
Login

Incremental Blob I/O and virtual tables

(1) By ddevienne on 2020-04-24 09:34:38 [source]

The doc for blob-open does not say anything about virtual tables,
yet the doc for virtual table does not appear to have entry points
for incremental blob I/O.

So is it supported? If not, could the doc be updated to be more explicit?
And is there any chance this could be supported in the (near) future?
Would there be a "work-around" via vtab-specific functions to emulate it?

If it is, through which virtual-table API(s) would that work?

Thanks for details on this subject. --DD

(2) By anonymous on 2020-04-24 17:34:46 in reply to 1 [link] [source]

As far as I know, it is not implemented (and can't be implemented with the current virtual table module structure without "faking it"). But it is a feature I also wanted, to add such things like:

int(*xBlobOpen)(sqlite3_vtab*,int writeable,sqlite3_int64 rowid,int column,sqlite3_vblob**out,int*size);
int(*xBlobClose)(sqlite3_vblob*);
int(*xBlobRead)(sqlite3_vblob*,unsigned char*buf,int offset,int length);
int(*xBlobWrite)(sqlite3_vblob*,const unsigned char*buf,int offset,int length);

(3) By ddevienne on 2020-04-24 22:58:25 in reply to 2 updated by 3.1 [link] [source]

Thanks for the support. At least I got *a* reply...

(3.1) By ddevienne on 2020-04-24 22:59:31 edited from 3.0 in reply to 2 [link] [source]

Thanks for the support. At least I got a reply on 1 of my 3 posts...

(4) By anonymous on 2020-04-25 02:23:35 in reply to 3.1 [link] [source]

There are a lot of other features I would want to see for virtual tables too; this is just one of them. I posted another message on this forum about my other ideas, so you can see if you have comment of it including possibly what I wrote is no good and you know how to make it better.

(5) By ddevienne on 2020-04-28 09:06:27 in reply to 4 [link] [source]

Please be more specific, with a link to that post.
There are many anonymous posts, narrowing the search to yours is impossible.

(6) By Tim Streater (Clothears) on 2020-04-28 11:38:31 in reply to 5 [link] [source]

Thus illustrating nicely why anonymous posts should be disallowed and posters should be obliged to use a unique handle.

(7) By Richard Hipp (drh) on 2020-04-28 13:25:16 in reply to 6 [link] [source]

I think it is important that people be allowed to post anonymously.

That said, anonymous posters need to understand that their posts carry less weight, and if they make ambiguous references to earlier posts (as Anonymous did at 3acf1639fe) then they are likely to be completely ignored.

(8) By ddevienne on 2020-04-28 14:35:04 in reply to 7 [link] [source]

I was hoping you were commenting on this thread's original subject.

I'm disappointed that it's again about anonymous. You're basically
the sole authority on SQLite internals and directions (and doc), and
normally quite rigorous in the doc about when something (e.g. an API)
can and cannot be used.

(9) By anonymous on 2020-04-28 17:15:16 in reply to 5 [link] [source]

I found it easily enough using the search function; here is the link: [524ccce544]