Jay A. Kreibich wrote:
On Tue, Jun 26, 2012 at 03:47:07PM +0200, OBones scratched on the wall:
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.
I understand that SQLite doesn't store the data, but I was thinking that
it stored the pointer to it during the "rename" internal procedure.
Hence my question about that.
Regardless, any possible saving of the state is up to the application.
Which is fine by me.
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.
Fair enough, I'm in discovery mode here, with some habits from my
experience but no hard expectations.
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'm definitely not fighting, merely discovering and learning along the
way. And because there were not so many discussions on virtual tables in
the archive, I thought that answers to my questions would help others in
the future.
Thanks for the pointers, I already read the documentation page and will
seek for the book.
Regards
Olivier
_______________________________________________
sqlite-users mailing list
[email protected]
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
