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-boun...@sqlite.org [mailto:sqlite-users-boun...@sqlite.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 Shaun Seckman (Firaxis) wrote: > 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 > 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkrvS4IACgkQmOOfHg372QTAEgCfRjO4Go5GrLeoB2Jj1as6sWwl iI8An0Zinzh/Bt8X1GWMr4agWGSnTdGN =vU0u -----END PGP SIGNATURE----- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
