NAME

DBD::Sys::CompositeTable - Table implementation to compose different sources into one table

ISA

DBD::Sys::CompositeTable
ISA DBD::Sys::Table
  ISA DBI::DBD::SqlEngine::Table

DESCRIPTION

DBD::Sys::CompositeTable provides a table which composes the data from several sources in one data table.

While constructing this table, the columns of the embedded tables are collected and a heading and a merge plan for the composed result table is generated.

Simplified example of table procs:

$alltables = $dbh->selectall_hashref("select * from procs", "pid");

# calls
# DBD::Sys::CompositeTable( [ 'DBD::Sys::Plugin::Any::Procs',
#                             'DBD::Sys::Plugin::Win32::Procs' ],
#                           $attr );

This will fetch the column names from both embedded tables and get (simplfied):

# %colNames = (
#     'DBD::Sys::Plugin::Any::Procs' => [
#       'pid', 'ppid', 'uid', 'gid', 'cmndline', 'sess', 'priority', 'ttynum', 'start', 'run', 'status',
#     ],
#     'DBD::Sys::Plugin::Win32::Procs' => [
#       'pid', 'ppid', 'uid', 'gid', 'cmndline', 'sess', 'priority', 'thread', 'start', 'run', 'status',
#     ]
# );
# @colNames = (
#       'pid', 'ppid', 'uid', 'gid', 'cmndline', 'sess', 'priority', 'ttynum', 'start', 'run', 'status', 'threads',
# );
# %mergeCols = (
#     'DBD::Sys::Plugin::Any::Procs' => [
#         0 .. 10,
#     ],
#     'DBD::Sys::Plugin::Win32::Procs' => [
#         7,
#     ]
# );
# $primaryKey = 'pid';

The merge phase in collectData() finally does (let's assume running in a cygwin environment, where Proc::ProcessTable and Win32::Process::Info both are working):

+-----+------+-----+-----+----------+------+----------+---------+-------+-----+---------+
| pid | ppid | uid | gid | cmndline | sess | priority |  ttynum | start | run | status  |
+-----+------+-----+-----+----------+------+----------+---------+-------+-----+---------+
|   0 |    0 |   0 |   0 | 'init'   |    0 |        4 | <undef> |     0 | 999 | 'ioblk' |
| 100 |    0 | 200 |  20 | 'bash'   |    1 |        8 |   pty/1 | 10000 | 200 | 'wait'  |
+-----+------+-----+-----+----------+------+----------+---------+-------+-----+---------+

+-----+------+-----+-----+----------+------+----------+-------+-----+---------+---------+
| pid | ppid | uid | gid | cmndline | sess | priority | start | run | status  | threads |
+-----+------+-----+-----+----------+------+----------+-------+-----+---------+---------+
| 782 |  241 | 501 | 501 | 'cygwin' |    0 |        4 |     0 | 999 | 'ioblk' |       2 |
| 100 |    0 | 501 | 501 | 'bash'   |    1 |        8 | 10000 | 200 | 'wait'  |       8 |
+-----+------+-----+-----+----------+------+----------+-------+-----+---------+---------+

The resulting table would be:

+-----+------+-----+-----+----------+------+----------+---------+-------+-----+---------+---------+
| pid | ppid | uid | gid | cmndline | sess | priority |  ttynum | start | run | status  | threads |
+-----+------+-----+-----+----------+------+----------+---------+-------+-----+---------+---------+
|   0 |    0 |   0 |   0 | 'init'   |    0 |        4 | <undef> |     0 | 999 | 'ioblk' | <undef> |
| 100 |    0 | 200 |  20 | 'bash'   |    1 |        8 |   pty/1 | 10000 | 200 | 'wait'  |       8 |
| 782 |  241 | 501 | 501 | 'cygwin' |    0 |        4 | <undef> |     0 | 999 | 'ioblk' |       8 |
+-----+------+-----+-----+----------+------+----------+---------+-------+-----+---------+---------+

In the real world, it's a bit more complicated and especially the process table is a bit larger, but it illustrates the most important points:

• missing columns are attached right

• missing rows are appended at the end of the first table (and are constructed as good as possible from the data we have)

• once existing data are neither verified nor overwritten (see the difference in the cygwin uid (root => uid 0) and win32 uid (Administrator => uid 501).

This is a fictive example - it's not verified how DBD::Sys behaves in cygwin! Maybe the user mapping works fine - maybe there will be no problem at all. Maybe you will get duplicated lines for each process with completely different data.

This is an experimental feature. Use with caution!

METHODS

new

sub new( $proto, $tableInfo, $attrs ) { ... }

Creates a new composite table based on the tables in $tableInfo, analyses the result view and create a merge plan for extending rows and appending rows.

The order of the embedded tables is primarily influenced by the priority of the table and secondarily by the alphabetic order of their package names.

In /DESCRIPTION example, DBD::Sys::Plugin::Any::Procs has a priority of 100 and DBD::Sys::Plugin::Win32::Procs has a priority of 500. So D::S::P::Any::Procs dominates.

getColNames

This method is called during the construction phase of the table. It must be a static method - the called context is the class name of the constructed object.

collectData

Merges the collected data by the embedded tables into one composed list of rows. This list of rows will be delivered to SQL::Statement when fetch_row is called.

The merge phase is demonstrated in the example in "DESCRIPTION".

AUTHOR

Jens Rehsack
CPAN ID: REHSACK
rehsack@cpan.org
http://search.cpan.org/~rehsack/

COPYRIGHT

This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself.

The full text of the license can be found in the LICENSE file included with this module.

SUPPORT

Free support can be requested via regular CPAN bug-tracking system. There is no guaranteed reaction time or solution time, but it's always tried to give accept or reject a reported ticket within a week. It depends on business load. That doesn't mean that ticket via rt aren't handles as soon as possible, that means that soon depends on how much I have to do.

Business and commercial support should be acquired from the authors via preferred freelancer agencies.

SEE ALSO

perl(1), DBI, Module::Build, Module::Pluggable, Params::Util, SQL::Statement.

cpanm DBD::Sys

perl -MCPAN -e shell
install DBD::Sys