D. Richard Hipp wrote:
On Tue, 2005-09-27 at 09:36 -0600, Brian Roe wrote:
I'm interested in using SQLite both at the SQL and BTree levels in an
application. That is, I would like to create tables and be able to run
queries using SQL while also inserting into, querying and updating
tables directly via the BTree-level C API calls (thus bypassing the SQL
subsystem entirely). Is there any information on how I can accomplish
this without corrupting data, confusing SQLite, etc?
The only documentation is comments in the code.
Note that the BTree-layer interface is not a published API.
It is subject to change in very incompatible ways without
notice. Such changes may be semantic only - meaning that
after upgrading SQLite you find that your application
compiles and links fine but generates subtle and difficult
to trace errors. The BTree interface is also fragile and
is not designed for external use. It lacks much of the
parameter checking that normally occurs on library routines
since the Btree interface is not intended for that use.
You will find that generating segfaults and corrupting
your database files will be quite easy if you call the
BTree layer directly. For these reasons, calls directly
into the BTree layer are strongly discouraged.
OK, excellent information; thank you.
Let me rephrase the question slightly: I'm interesting in bypassing the
SQL layer when possible, while not breaking compatibility with SQL. I
am not specifically interesting in using BTree-layer calls, that just
seemed to be the obvious next layer down below the SQL subsystem.
Perhaps the use of EXPLAIN would show the way to implement certain types
of common accesses I expect to be done frequently, such as inserting one
row, selecting one row using a unique key or updating one row. Then I
could correlate the virtual machine instructions with specific supported
API calls? Meanwhile, SQL would still work for reporting or other types
of ad-hoc queries. Or is there a better way? Thanks.
