This web mail archive is frozen.
This page is part of a frozen web archive of this mailing list.
You can still navigate around this archive, but know that no new mails
have been added to it since July of 2016.
Click here to be taken to the new web archives of this list; it includes all the mails that are in this frozen archive plus all new mails that have been sent to the list since it was migrated to the new archives.
WHAT: Revamp the opal database framework, including renaming it to "dstore" to reflect that it isn't a "database"
WHY: The original modex datastore operation became entangled with true database APIs
for things like Postgres. In addition, George has proposed a cleaner separation of modex
data, organized by code layer and perhaps other attributes
WHEN: April 29th, barring issues
***** Details *****
The "db" framework was originally located in ORTE, and was used for database-related operations in support of the sensor framework. It was then extended to hold and support the modex data, and subsequently moved to the OPAL level in anticipation of the BTLs moving down there. At the current time, it has several APIs relating to modex support, and one API for general database operations. In order to separate out modex info between BTL data that must be shared with peers, data which only needs to be swapped during comm-spawn, and data used only for internal support, we created an "opal_scope_t" and require that you tag your data with one those three scopes when it is "stored". You then fetch data based on the scope as well as the key.
This change does the following:
* moves the pure database operations to a new ORTE "db" framework - basically, restoring the database operations to where they used to be. This includes moving the postgres, print, and sqlite components
* renames the modex datastore framework in OPAL to "dstore", leaving the hash and pmi components there.
We have removed the opal_scope_t designation. The modex datastore framework instead now includes the concept of a "handle" that is somewhat equivalent to a POSIX file descriptor. You "open" a datastore and return a handle for that storage area - all subsequent calls to store and fetch data must provide the handle indicating the storage area. Each handle actually translates into a unique module, so the data remains completely isolated from any other handle.
Only one datastore component can be selected. Thus, the pmi component now includes its own hash table storage, and we've put the common hash table support code in the datastore base.
The database framework operates the same way as the datastore, except that it allows multiple components to be active, and for the caller to specify the desired database backend when "opening" the database handle.