Free mldbm software for linux

MLDBM::TinyDB is a Perl module that can help you to create and manipulate structured MLDBM tied hash references.

SYNOPSIS

use MLDBM::TinyDB;
## or
use MLDBM::TinyDB qw/db add_common/;

@common = qw/created updated/; ## optional

$tree = [TABLE, FIELDS_LIST,
[TABLE1, FIELDS_LIST1,
[TABLE2, FIELDS_LIST2],
...
],
...
];

MLDBM::TinyDB::add_common($tree,@common); ## optional
## or
add_common($tree,@common);

%obj = ();
$obj{TABLE} = MLDBM::TinyDB->init(TABLE, $tree);
## or
$obj{TABLE} =
MLDBM::TinyDB->init(TABLE, $tree, undef, $mode, $perms);
## or
$obj{TABLE} = MLDBM::TinyDB->init(TABLE); ## NEVER FIRST TIME

@down = $obj{TABLE}->down; ## TABLE1

$obj{TABLE1} = MLDBM::TinyDB::db(TABLE1);
## or
$obj{TABLE1} = db(TABLE1);

$table = $obj{TABLE}->table; ## TABLE

@down = $obj{TABLE1}->down; ## TABLE2

$obj{TABLE2} = MLDBM::TinyDB::db(TABLE2);
## or
$obj{TABLE2} = db(TABLE2);

@set_recs_indices =
$obj{TABLEn}->set_recs(ARRAYREF_TO_HASHREF,[LIST]);

$up = $obj{TABLE2}->up; ## TABLE1

$aref_of_href = $obj{TABLE}->get_ext_recs;
## or
($aref_of_href, @get_recs_indices) = $obj{TABLE}->get_ext_recs;

$aref_of_href1 = $obj{TABLE}->get_recs; ## NOT THE SAME AS ABOVE
## or
($aref_of_href1, @get_recs_indices1) = $obj{TABLE}->get_recs;

@indices_of_recs_found = $obj{TABLE}->search($criteria, [$limit]);
@indices_of_recs_found = $obj{TABLE}->lsearch($criteria, [$limit]);

@indices_and_sort_field_values = $obj{TABLE}->sort($sort_formula_string);
@indices_and_sort_field_values = $obj{TABLE}->lsort($sort_formula_string);

$obj{TABLEn}->delete([LIST]);
$obj{TABLEn}->last;

MLDBM::TinyDB is MLDBM based module. It allows to create/manipulate data structure of related tables = more-then-flatfile-database. The main idea is to create array reference which will reflect database structure. The first scalar value in the array is table name, next ones are fields names - if the array contains array reference it denotes interior (related) table where first scalar value is that table name (in that case the record will contain the field of the same name as interior table) and the next ones are fields names and so on... If database structure isnt written on disk then that structure is fetched from the array reference and written to disk.

Object is always built from disk structures. To define record you may use any field name except "nodes" which is restricted field name and shouldnt be specified explicitly. created and updated fields are handled internally - if they are specified then: 1)on append record operation time function value is set to created record field 2)on write to existing record operation time function value is set to updated record field. Data get from and set to records are in form of array reference to hash references where hash keys are fields names. The fields names that are interior tables names contain array references. That array store indices (similar to array indices) identifying particular records. Those fields MUST be set to proper values before write records set_recs operation.

DBM::Deep is a pure perl multi-level hash/array DBM.

SYNOPSIS

use DBM::Deep;
my $db = DBM::Deep->new( "foo.db" );

$db->{key} = value; # tie() style
print $db->{key};

$db->put(key => value); # OO style
print $db->get(key);

# true multi-level support
$db->{my_complex} = [
hello, { perl => rules },
42, 99,
];

A unique flat-file database module, written in pure perl. True multi-level hash/array support (unlike MLDBM, which is faked), hybrid OO / tie() interface, cross-platform FTPable files, and quite fast. Can handle millions of keys and unlimited hash levels without significant slow-down. Written from the ground-up in pure perl -- this is NOT a wrapper around a C-based DBM. Out-of-the-box compatibility with Unix, Mac OS X and Windows.

Puppet::Any provides a common base class for lab development tools.

Puppet::* classes are designed to provide an access to the "puppeted" object using a GUI based on Tk.

The basic idea is when you construct a Puppet::* object, you have all the functionnality of the object without the GUI. Then, when the need arises, you may (or the class may decide to) open the GUI of the object and then the user may perform any interactive he wishes.

On the other hand, if the need does not arise, you may instanciate a lot of objects without cluttering your display.

For instance, if you have an object (say a ProcessGroup) controlling a set of processes (Process objects). The user may start the ProcessGroup through its GUI. Then all processes are run. If one of them fails, it will raise its own GUI to display the cause of the problem and let the user decide what to do.
This class named Puppet::Any is the base class inherited by all other Puppet classes. In this example, Process and Process group both will inherit Puppet::Any.

The base class features : - A Tk::Multi::Manager to show or hide the different display of the base class (or of the derived class) - A menu bar - An event log display so derived object may log their activity - A Debug log display so derived object may log their "accidental" activities - An Object Scanner to display the attribute of the derived object - A set of functions to managed "has-a" relationship between Puppet objects. The menu bar feature a "content" bar which enabled the user to open the display of all "contained" objects. - a facility to store data on a database file tied to a hash.

The class is designed to store its data in a SINGLE entry of the database file. (For this you should use MLDBM if you want to store more than a scalar in the database). The key for this entry is "$keyRoot;$name". keyRoot and name being passed to the constructor of the object. Needless to say, its a bad idea to create two instances of Puppet::WithDb with the same keyRoot and name.