On Tue, Jun 26, 2012 at 03:47:07PM +0200, OBones scratched on the wall: > Hello all, > > I'm experimenting with virtual tables and I must say that it's a > very nice feature to have, it saves me from inserting millions of > records in a database when I can simply map the source file in > memory and read it directly. > However, I have a small issue when renaming a database. What is > happening is the following: > > xDisconnect > xRename > xConnect
> Those calls are quite expected and fine by me. > However, what surprises me is that xConnect is given a zero ppVTab > parameter (that is, *ppVTab == 0) The whole point of both the xCreate() and xConnect() functions is to allocate, define, and return the sqlite3_vtab structure. It must be allocated by the xCreate()/xConnect() function because it is standard practice to over-allocate the data structure so that the virtual table can append additional data fields to the end of the sqlite3_vtab structure. Since SQLite has no idea how much extra memory you might want, it is up to the functions to allocate this structure and pass it back to SQLite via the ppVTab parameter. This exact same pattern can be seen in xOpen(), where the virtual table is tasked with allocating, init'ing, and returning the sqlite3_vtab_cursor structure. In xClose(), the virtual table must clean-up and deallocate the same structure. Again, it is standard practice for virtual tables to over-allocate this data structure, so the actual memory allocation needs to be done by the virtual table code, not by SQLite. > I would have thought that since the disconnect was given a valid > pVTab, this one could have been given back to xConnect when > reconnecting the database after its rename. Except SQLite doesn't store the data in that structure. sqlite3_vtab is a "live" structure, in the sense that it only exists in-memory in an active database process. The whole idea of xCreate()/xConnect() is to re-create this data structure, every time, from the original virtual table declaration. The whole point of xDestroy()/xDisconnect() is to clean up, destroy, and free the sqlite3_vtab structure. It only exists between a pair of those calls. If you're trying to keep track of some type of connection information or external file-name or something, it is best that such information is part of the CREATE VIRTUAL TABLE statement, as this data will always be available. In theory, your application could save the partial state of any custom fields in xDisconnect() and then read them back in xConnect(). Any application that uses "shadow tables" (such as the built-in FTS and R-Tree modules) essentially does this, as there is state saved into the database the virtual table uses to provide its service. These types of virtual tables have different xCreate()/xConnect() functions and different xDestroy()/xDisconnect() functions, as one set of functions needs to create/drop the shadow tables, while the other set only needs to verify that they're there. Regardless, any possible saving of the state is up to the application. > Is this behavior expected? I'm fine with my current solution, but I > was expecting xConnect to get a non zero *pPVTab most, if not all > the time. This is exactly how the API is designed. You seem to be fighting the API, which makes me think there might be a slight disconnect between how you expect the API to work and how the API was designed to be used. I would recommend you have a good read through all the docs on the SQLite website about virtual tables, especially this: http://www.sqlite.org/vtab.html The book "Using SQLite" (O'Reilly) also has an entire chapter on virtual tables and how to use them. It happens to be the longest chapter in the book, and walks through two full examples. One of the examples is using a virtual table to map web-server logs to an SQLite table without importing the data. From what you said, that sounds somewhat similar to your problem. http://shop.oreilly.com/product/9780596521196.do -j -- Jay A. Kreibich < J A Y @ K R E I B I.C H > "Intelligence is like underwear: it is important that you have it, but showing it to the wrong people has the tendency to make them feel uncomfortable." -- Angela Johnson _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
