RE: Berkeley DB with Euphoria
- Posted by rudy toews <rltoews at ilos.net> Sep 30, 2002
- 420 views
Andy Serpa wrote: > I cached the key_pointers in my version in a very simple way. Speeded > it up enormously when flipping between tables. When it selects a table, > > if there is already a "current table" it saves the pointers for that > table in a global sequence, then it checks to see if it already has the > key pointers for the new table in memory, and if so grabs them, or else > loads them in as normal. > > On a db_close or db_open it clears them out, so it only works if you're > using one db at a time (with an exclusive lock). I only had to add > maybe 10 lines. > > To keep multiple databases open without selecting between them all the > time (a fixed, known number of them), I believe (I haven't tried it) the > > "namespace trick" would work, even if it is an ugly solution: > > include database.e as dbA > include database.e as dbB > > Now using namespaces with all the db functions you could keep them > separate, right? > > > Robert Craig wrote: At the very outset, in designing EDS, I had a choice > > of: > > 1. have the user specify the database & table > > on each operation, > > or: > > 2. have a "context" where the database and > > table were established beforehand, and all database > > operations would have shorter parameter lists. > > > > I went with #2. I don't regret it, but there are situations > > where it is inconvenient. > > > > When you select a table, EDS reads in 4 bytes per record > > in that table. This is inefficient when you have a lot of records > > (over 1000 say) and you are trying to rapidly flip back and forth > > between tables. Obviously some buffering would help, > > i.e. keep the record pointers in memory. Maybe I'll do something > > about this. Note that it's dangerous to modify part of the data base > > structure in memory only, in case your program crashes > > and the database on disk is left in an inconsistent (corrupted) state. > > Simply keeping a copy of the record pointers in memory > > should be safe as long as other processes are locked out from > > making changes. There's also the issue of how much memory > > this might require. If you have lots of tables with lots of records > > you might run out of memory. > > > > If you look at db_compress() you'll see that it copies records, > > between tables, 20 at a time. That's another approach > > to the problem. Thankyou Rob and Andy hmm, i didn't really think of making a copy of the database functions and renaming them so they don't get mixed. i will give it a shot when i have progressed more on my windows programming level. almost understand how statements start to fit together to get what i want done. (danger level). recently i have seen the colon used in functions that Phil Russel is working on in creating EuGrid. i forgot what the notation below means, i have seen it before but i don't remember (win32lib or somedatabase routines). newkey = noah:saveanimal(dataset[i]) does it let noah refer to the current open window or .e file? allowing multiple uses of the same function name? thanks again rudy the use of the colon lotterywars