view release on metacpan or  search on metacpan

DB.pm  view on Meta::CPAN

    # FIXME : this needs to be much more robust

    my $edb_class = "Embedix::DB::" . $opt{backend};

    my $self = $edb_class->new(source => $opt{source});

    return $self;
}


1;

__END__

=head1 NAME

Embedix::DB - persistence for ECDs

=head1 SYNOPSIS

instantiation

    my $edb = Embedix::DB->new (
        backend => 'Pg',
        source  => [ 
            'dbi:Pg:dbname=embedix',
            'user', 'password',
            { AutoCommit => 0 },
        ],
    );

    # $edb should be an instance of Embedix::DB::Pg

adding a distro

    $edb->addDistro (
        name  => 'uCLinux 2.4',
        board => 'm68k',
    );

    $edb->addDistro (
        name  => 'Embedix 1.2',
        board => 'ppc',
    );

selecting a distro to work on

    $edb->workOnDistro(name => 'Embedix 1.2', board => 'ppc');

cloning a distro

    $edb->cloneDistro(board => 'mpc8260adsp');

updating a distro with new information

    my $apache_ecd = Embedix::ECD->newFromFile('apache.ecd');
    $edb->updateDistro(ecd => $apache_ecd);

deleting components from a distro

    $edb->deleteNode(name => 'busybox');

=head1 REQUIRES

=over 4

=item Embedix::ECD

This is needed to get data from ECD files into perl objects that can
then be inserted into a database.

=item DBD::Pg

The PostgreSQL backend uses this.

=item DBD::mysql

If anyone writes a MySQL backend, it'll surely use this.

=back

=head1 DESCRIPTION

The "DB" in Embedix::DB stands for database.  Although Embedix::DB was
inspired by the B<tigger> code that implements the original Embedix
Database, the implementation strategy is quite different.

First, Embedix::DB is a means to provide persistence for data found in
ECD files.  Tigger uses the filesystem for this purpose.  Embedix::DB
may have a filesystem-based backend in the future, but the current
implementation provides a PostgreSQL-based backend.  The goal here was
to minimize the amount of parsing necessary to start an Embedix
configuration program (like TargetWizard).  By doing the CPU-intensive
parsing stage only once for when an Embedix distribution is initially
defined, startup can be much faster.  TargetWizard currently parses a
large collection of ECDs every time it starts up.

Beyond that, it has the ability to take ECD data and organize it
at a higher level into distributions.  Currently, it is awkward to use
a single TargetWizard installation to provide the ability to configure
different distributions.  For example, you could not use TargetWizard to
configure both a uCLinux distribution and an Embedix distribution during
the same session.  In order to do this, one would currently have to exit
TargetWizard, install a new config that points to the appropriate
directories, and restart TargetWizard.  Although tigger is theoretically
capable of handling this more gracefully, the directory structure for
how ECDs are stored doesn't facilitate this.  In contrast, Embedix::DB
was designed from the beginning to be able to manipulate multiple
distributions simultaneously.

Another area where Embedix::DB deviates from tigger is in node names
for ECDs.  Tigger requires that all nodes must have B<unique> names
regardless of the node's nesting.  Embedix::DB does not have this
restriction.  Hopefully, this will allow node names to be less contrived
in the future.

One significant difference between Embedix::DB and tigger is that
Embedix::DB does not handle dependency and conflict resolution.  That
job is delegated to Embedix::Config which will use an instance of
Embedix::DB to get information from the database when necessary.  Also
note that Embedix::DB does not know how to parse or generate ECD files.