On Mon, Apr 8, 2013 at 8:20 AM, Max Vlasov <max.vla...@gmail.com> wrote:
> Richard,
>
> It makes sense, but I see here some possibility of future confusion.
> Correct me if I'm wrong. Currently if I have a vfs that requires special
> preparations (for example, decompression), I have two choices, either
> provide V2 interface or emulate memory-mapping by allocating my own blocks
> of memory in xFetch and deallocating in xUnfetch. If future V4 IO routines
>
You an implement xFetch to always return NULL:
int xFetch(sqlie3_file *pNotUsed1, i64 notUsed2, int notUsed3, void
**pp){
*pp = 0;
return SQLITE_OK;
}
Then SQLite will always fallback to doing plain old xRead and xWrite.
> introduce something new, one will not have the first option. So anyone in
> the future should be aware that there are two points where data can be
> needed and since one expects filling previously allocated block and another
> expects pointer to the data, the complexity of understanding will grow. Or
> is there a simple way to disable xFetch/xUnfetch on the VFS level?
>
> Max
>
>
>
>
>
> On Mon, Apr 8, 2013 at 3:33 PM, Richard Hipp <d...@sqlite.org> wrote:
>
> > On Mon, Apr 8, 2013 at 6:12 AM, Max Vlasov <max.vla...@gmail.com> wrote:
> >
> > > But I also noticed that if I provide
> > > version 2 of vfs, I won't get benefits of file-mapping
> > >
> >
> > That's how we implement backwards compatibility to legacy VFSes.
> >
> > --
> > D. Richard Hipp
> > d...@sqlite.org
> > _______________________________________________
> > sqlite-users mailing list
> > sqlite-users@sqlite.org
> > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
> >
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
--
D. Richard Hipp
d...@sqlite.org
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
