> Currently this means adding > the new columns to my C-structures, writing access functions, and > recompiling. I don't want to do that, because this means my appl *must* > be replaced on every database change, and I'd like to be able to > run different versions of it in the wild. I was hoping to make it > more dynamic and adaptive to database layout changes.
Sorry, Ron, but I don't get it. You're saying that adding more columns means adding more fields into your structure and making your application to know about those fields, and that means you need to recompile and it's a bad thing. But if you're working with SQLite's in-memory database then you have to create all tables in that database at startup, so you need an SQL statement in your application containing all columns you use, so again adding a column you need to recompile, right? Or if you generate your CREATE TABLE statement dynamically from postgresql then how does your code know about new fields added? How does it work with it? Are your newly added columns used only from sql coming directly from clients? Maybe you just need to re-think your database schema so that you need only one select statement per network request and so your requirements to sql engine speed would be lowered by the order of magnitude? Pavel On Sun, Oct 18, 2009 at 2:23 PM, Ron Arts <r...@arts-betel.org> wrote: > P Kishor schreef: >> On Sun, Oct 18, 2009 at 10:37 AM, Ron Arts <r...@arts-betel.org> wrote: >>> Very true Simon, >>> >>> this has been the fastest way so far and I can do around >>> 350000 selects/second this way, using prepared statements >>> (on my machine at least), but I need more speed. >>> >>> That's why I want to skip the SQL processing entirely >>> and write a C function that reaches directly into the >>> internal memory structures to gets my record from there. >> >> I might have missed the discussion, but... why don't you ditch SQLite >> and use something like Berkeley DB? Sounds to me you need a hash db >> instead of an rdbms, especially since you have no need for SQL. >> > > Well, that's what I use at the moment (I use glib2 g_hash_table()), > but now the requirement to accept SQL queries for that database > has come up. And I don't want to write my own SQL parser.. > > Next I tried to add a virtual table driver to SQLite for my database. > That worked, but because the application is evolving, columns > get added/changed on a regular basis. Currently this means adding > the new columns to my C-structures, writing access functions, and > recompiling. I don't want to do that, because this means my appl *must* > be replaced on every database change, and I'd like to be able to > run different versions of it in the wild. I was hoping to make it > more dynamic and adaptive to database layout changes. > > Thanks, > Ron > > >> >>> thanks, >>> Ron >>> >>> Simon Slavin schreef: >>>> On 18 Oct 2009, at 8:37am, Ron Arts wrote: >>>> >>>>> Is there a way to bypass the virtual machine altogether and reach >>>>> directly >>>>> into the btree and just retrieve one record by it's oid (primary >>>>> integer key), >>>>> and return it in a form that would allow taking out the column >>>>> values by name? >>>> The primary integer key column can always be referred to as the >>>> special name ROWID, even if you have assigned it a column name of your >>>> own. So you can do >>>> >>>> SELECT ROWID,myCol1,myCol2 FROM myTable >>>> >>>> as long as you don't explicitly declare a primary integer key column >>>> and then change the values in it. >>>> >>>> Simon. >> >> >> >> >> > > _______________________________________________ > 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
