The SQLite Consortium membership would be great but so far this
newsgroup has answered every single one of my questions within a 2 hour
window of posting..for free! (you guys frickin rock.) So SQLite
development is purely guided by requests from consortium members? There
aren't any planned features that the developers wish to include just for
maintenance or to add to already amazing feature set and polish of
SQLite? As for buying the extension, I remember seeing it in the list
of professional support a few months ago but it currently isn't listed
anymore.
The limitations of the prepared byte code you mention are pretty
acceptable in our use case. As you mentioned, my main reasons for
wanting this sort of feature is to reduce memory consumption and cpu
time from preparing statements and as an added benefit to have a
singular point where all prepared statements are located and could be
tested prior to use (granted, this could be done already via some
architecture and build process tweaks to my project). As for the byte
code not working with future versions of SQLite, we typically generate
the database file on the fly the first time the application is run, then
load it from disk for all subsequent runs. This cached database is
destroyed whenever a newer version of the exe is built (so new version
of SQLite would just require us to invalidate our cache and regenerate
it). The schema changes are a bit of a drag but would be rare and in
that case any prepared statement that is invalidated by them could just
be re-prepared.
Another potential feature that could benefit my usage and possibly
others is if prepared statements could use memory allocated from the
stack rather than the heap or if memory allocated for one statement
could be reused for another one (assuming that previous statement has
been completely finalized). I can understand this being very tricky to
implement since you must clearly define what items have the same
lifetime as the statement and which ones may be passed on later (ie.
strings).
It's not an absolute requirement for me right now though, just a nice to
have. So far I've really been impressed with the performance of SQLite
and the ability to bind parameters to prepared statements has met many
of my needs. In fact, the only major problem I've had with SQLite is
that the amount of polish has spoiled me and often makes me disgusted
when using other third party libraries which I won't name. (If only
other libraries had 100% branch coverage..)
-Shaun
-----Original Message-----
From: sqlite-users-bounces-CzDROfG0BjIdnm+***@public.gmane.org
[mailto:sqlite-users-bounces-CzDROfG0BjIdnm+***@public.gmane.org] On Behalf Of Roger Binns
Sent: Monday, November 02, 2009 4:14 PM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] Roadmap for SQLite
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Post by Shaun Seckman (Firaxis)I'm really interested in finding out what sort of major features or
tweaks are planned to be in upcoming releases (within the next 6
months).
You get what you ask for :-) Have a look at these two pages:
http://www.sqlite.org/consortium.html
http://www.hwaci.com/sw/sqlite/prosupport.html
Post by Shaun Seckman (Firaxis)I'm also hoping
that storing prepared statements inside of a database is a planned
feature as well since having a bunch of SQL queries embedded in my C++
leaves me nervous :)
You can buy an extension that does that (as has been pointed out several
times on this list). However what is wrong with storing the unprepared
SQL
queries?
The prepared queries are byte code for the SQLite virtual machine (aka
VDBE). The generated byte code changes with each release (that is how
many
features are added and bugs fixed), so you wouldn't want to keep them
over
SQLite version changes. The normal use case is for limited environments
where you don't want the memory consumption of the SQLite parser. The
parsing is done ahead of time on the build workstation before putting
the
database containing them onto the embedded device. Note that you also
can't
change the database schema in any way since that invalidates the
pre-generated byte code.
Roger