NAME

Table::Denormalized - Dynamically add columns to a table

SYNOPSIS

  use Table::Denormalized;
  my $table = Table::Denormalized->new(
    table     => 'my_table',
    primary   => '_id',
    row_class => 'My::Special::Row',
  );

  $table->create;

  # somewhere else, later:

  $table->add_set(@columnsets);
  $table->alter_table;

  # The table now has all columns as specified in the column sets

ABSTRACT

This module provides the scaffolding to dynamically add (and in the future also remove) columns from a database table.

`new`

Constructs a new instance.

  dsn               DBI connect string
  dbh               A valid dbh - may be given instead of the DSN
  columnsets            The column sets, can also be added via add_set
  table             The name of the table, default is 'file_cache'
  primary           The name of the primary key, default is '_id'
  row_class         The class single rows will be blessed into. The default
                    is "$class::Row", which should inherit from
                    Table::Denormalized::Row

`columns`

Enumerates the columns and returns them in alphabetical (sort) order.

`add_set SETS`

Adds one or more new column sets to the table, but does not yet alter the table.

`missing_columns`

Returns the columns that are in the column sets but are not yet in the table structure of the database.

`alter_sql`

Returns the SQL commands that need to be executed to alter the table structure to what the column sets specify.

Currently will only generate ADD COLUMN statements and never DROP COLUMN statements. This seems to be sensible because different programs might want to use the same table.

`alter_table`

Actually executes the statements returned by alter_sql and thus brings the table in synch with the specification.

`rows_to_objects ROWREF`

Blesses all rows in the array reference given by ROWREF into the desired class and adds a weak backlink to the table to each row.

If you want to switch this behaviour to use a real class constructor or to use a different class like a DBIx::Class derivative, you will have to override this method in your subclass or replace this method directly.

Replacing this method should be fairly sane since you will likely want to use DBIx::Class in your whole project if you use it in one place already.

`query WHERE`

Returns the blessed results of an SQL::Abstract select WHERE expression. The results will be stored in an array reference which is blessed into a Table::Denormalized::Resultset.

`query_ex ARGS`

(for lack of a better name) runs a full pass-through to a SQL::Abstract::SuperSearch query retrieving all columns unless given.

`retrieve ITEMS`

Shortcut to retrieve rows by their primary key

`all`

Returns all rows stored in the table.

`delete ITEMS`

Deletes all rows as given by their primary key values.

`update ITEMS`

Saves the data from the hashrefs given by ITEMS into the table.

A WORD FROM THE AUTHOR

This module is clearly an example of the "Worse Is Better" idea - the underlying database "design" is horrible and has many drawbacks, chiefly that it's not relational, but it has the huge advantage if simplifying and streamlining the code that operates on the table and with the results.

The module came in to existence after I had failed to implement five generations of well-designed database schemata, mostly because the handling was too complex to understand after the code had rotted for a week.

AUTHOR

Max Maischein, <corion@cpan.org>