OpenEuphoria

RE: Berkeley DB with Euphoria

• Posted by Andy Serpa <renegade at earthling.net> Sep 30, 2002
• 404 views

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:
> Rudy Toews writes:
> > ...could something similar be a feature of EDS? having the 
> > different open databases /selected tables use their own 
> > 'buffers' without explict 'selecting' them?
> > i am currently building 1 database and many tables 
> > but would like to break it up somewhat. and still move data 
> > between them easier.
> 
> 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.
> 
> Regards,
>    Rob Craig
>    Rapid Deployment Software
>    http://www.RapidEuphoria.com
> 
>