Daniel's concept is that of Embedded SQL, a marriage not quite made in
heaven probably because of the clumsiness in integrating the database
schema and the data definitions of legacy languages.
At one time we built a byte-coded implementation of a legacy language
which did exactly as Daniel proposes, compiled the embedded SQL into the
equivalent of the Sqlite VBDE and executed that at runtime. It realized
the benefits Daniel predicts. The benefits were more evident back in an
area of far slower machines than you would see today.
Christian Smith wrote:
Daniel Önnerby uttered:
Hi everyone!
I'm just a bit curios if it would be possible to make like a C
precompiler or a macro of some kind that compiles/interpret the
SQL-statements to bytecode just like the sqlite_prepare does but does
this when compiling/precompiling your application instead of at
runtime. Since most application written in C/C++ use static
SQL-statements (unless you are building your SQL-strings on the fly)
and then bind the values, I guess there would be several benefits for
your compiled application:
* Faster: Since the SQL-statement is already interpreted.
* Smaller (not that sqlite needs to be smaller): The executable does
not need to contain the part of sqlite that interprets the
SQL-statements since this was made at compile time.
Run time compilation is not that expensive if the generated vm is
cached. Just have a per-connection hash, use the SQL as the hash key,
and the resulltingvm as the value. Upon first use, the SQL will not be
in the hash, and will be compiled and inserted. Subsequent uses of the
same SQL will be quickly retrieved from the hash and used as is.
This is how the TCL wrappers work, I believe.
Just a thought :)
Best regards
Daniel Önnerby
--
/"\
\ / ASCII RIBBON CAMPAIGN - AGAINST HTML MAIL
X - AGAINST MS ATTACHMENTS
/ \
