OONumerics User : |
From: Michael Soliman (msoliman_at_[hidden])
Date: 2001-07-19 05:55:31
Moin Moin.
> Michael Soliman writes:
> > Moin Moin.
> >
> > Did anyone hear of a map<.,.,.,.>-implemantation, shadowing its data
into
> > a database [maybe by replacing the normal allocator-mechanism as to
hand
> > out the map's index-parameter as a parameter to the allocators.
> The runtime complexity of a database update and a memory chunk
> allocation is magnitude far apart, the former one typically involves
> at least one network roundtrip unless you're using embedded
> database plus some constraint check etc. Therefore it doesn't sound a
> good idea to bundle them together at such fine grain even though
> syntatically it can hide the dirty database work beneath.
>
> If all you need is to update the database with the data in the map,
> why not write a helper method/class to do the database work? That way,
> all you need from the content side is an iterator of desired key and
> value type of an associative container, which includes not only
Hm. I assume that, by saying "associative", You mean, that the container
comprises a bijective function
binding together map-elements and database-table-entries.
> map<...>, but a whole lot more. Note that you don't have to change any
> existing container code. On the DB interface side, you can devise
> some common interface expected of your application, and then provide
> concrete impl for different DBMS or even other data persistence means
> like a zip file.
Ok. This does the job as I lined it out.
But my initial idea was to have some fast access to database-"shadowed"
data, rather than using ONE db-access per map<.,.,.,.>-access.
As I heard the allocators to be intended for use on different "kinds" of
memory (say DRAM as well as FLASH). I thought one could use this mechanism,
to implement some sort of virtual-memory-machine.
It could execute the map<.,.,.,.>-accesses using the DRAM, as long as the
data can be found in the db and as long as it has been read.
Otherwise it could execute something like a page-fault just alike any other
virtual-memory-system, accessing the database instead of a swap-file.
This would have the advantage, that You could perform fast arithmetics on
this kind of a map, as it would be using the same kind of
(compiler-optimised) source as the normal STL-map<.,.> as long as no
allocator is called.
In essence, it would mean to use the
virtual-memory-machine-"hardware-acceleration" (i.e., the MMU) to decide,
whether the data has to be read from the db.
What Do You think. Can this task be performed using the standard-STL-text
and, thus, moving the machine-dependent stuff into the allocator (or some
other mechanism-comprising class) class.
Tschuess,
Michael.
--------------------- Object Oriented Numerics List --------------------------
* To subscribe/unsubscribe: use the handy web form at
http://oonumerics.org/oon/
* If this doesn't work, please send a note to owner-oon-list_at_[hidden]