On Apr 9, 2008, at 10:26 AM, Aladdin Lampé wrote: > > Hi Phil and list! > > Thank you for this very instructive post about SQLite's internals > and btrees. I'm just curious about what could be real-life use cases > of having direct access to the btree stuff. As I understand your > example, you store (key,value) pairs inside the btree and then get > them back. Then, what's the purpose of not using a normal SQLite > table to do so? > > On the other hand, since those "direct btree information" are > necessarily stored inside a reguar SQLite file, doesn't this > introduce possible side effects with other functions of the sqlite > library, which would not be aware that some btree roots inside the > file are neither a table nor an index? (vacuum, etc.) > > Last but not least, I am currently developping a virtual table and > I've just realized that I could use SQLite btrees for indexing data > coming from an "external database" (cf recent thread about virtual > tables and access to big external databases). > According to you, would it be a good idea to use this technique in > order to implement an alternative indexing technique (for "external > tables") based on SQLite btrees? > > Thanks a lot for sharing about that, any help would be greatly > appreciated,
The use of SQLite's internal BTree routines by external applications is fraught with peril and is strongly discouraged. The BTree interface changes, sometimes in very subtle ways, without notice and with no documentation apart from comments on the code. And the BTree routines are not tested except for the usages modes employed by SQLite itself. If you ignore this advice and decide to use the BTree routines directly, and your code breaks or malfunctions due to some unseen subtly or some future change, then the rule is: "No Tears". D. Richard Hipp [EMAIL PROTECTED] _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
