On Fri, Jun 14, 2013 at 1:16 PM, Simon Slavin <slav...@bigfraud.org> wrote: > > > On 14 Jun 2013, at 5:56pm, Maxim Khitrov <m...@mxcrypt.com> wrote: > >> Unconditionally invalidating the cache after each initial call to step >> will add a bit of overhead when repopulating the values. > > Do you think that every single user of SQLite does this ? Have you ever seen > it included in the source code of any application that uses SQLite ? > > I don’t know quite what you’re worried about. Do you actually expect your > schema to be changed when you’re in the middle of a SELECT ? And don’t you > think that if the schema did change it would be better for your application > to show the user an error code so your user would realise that the database > they were consulting was now holding different kinds of data ?
There is no application. I'm writing SQLite bindings for Go [1]. Calling into C is expensive, as is the conversion from C to Go strings. I don't load any column metadata initially, but if the user asks for it, then I'd rather cache what I can and return it quickly the second time around. The current implementation assumes that column counts, names, and declarations never change, which I realized was incorrect. I'm trying to find the optimum way of invalidating the cache precisely because it is rare for the schema to change. After the initial load, the cache will likely stay valid for the lifetime of the statement. But if recompilation does happen, I need a cheap way to detect this. [1] http://code.google.com/p/go-sqlite/ _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
