1;
__END__
+
=head1 NAME
-DBIx::Class::ResultSource::MultipleTableInheritance -- Use multiple tables to define your classes
+DBIx::Class::ResultSource::MultipleTableInheritance
+Use multiple tables to define your classes
+
+=head1 NOTICE
+
+This only works with PostgreSQL for the moment.
=head1 SYNOPSIS
{
package MyApp::Schema::Result::Coffee;
- __PACKAGE__->table_class('DBIx::Class::ResultSource::MultipleTableInheritance');
+ __PACKAGE__->table_class(
+ 'DBIx::Class::ResultSource::MultipleTableInheritance'
+ );
__PACKAGE__->table('coffee');
__PACKAGE__->add_columns(
"id",
my $cup = $schema->resultset('Sumatra')->new;
- print STDERR Dumper $cup->columns;
+ print STDERR DwarnS $cup->columns;
$VAR1 = 'id';
$VAR2 = 'flavor';
$VAR3 = 'aroma';
-Inherit from this package and you can make a resultset class from a view, but that's more than a little bit misleading: the result is B<transparently writable>.
-
-This is accomplished through the use of stored procedures that map changes written to the view to changes to the underlying concrete tables.
+Inherit from this package and you can make a resultset class from a view, but
+that's more than a little bit misleading: the result is B<transparently
+writable>.
+This is accomplished through the use of stored procedures that map changes
+written to the view to changes to the underlying concrete tables.
=head1 WHY?
-In many applications, many classes are subclasses of others. Let's say you have this schema:
+In many applications, many classes are subclasses of others. Let's say you
+have this schema:
# Conceptual domain model
class User {
- has id,
- has name,
- has password
+ has id,
+ has name,
+ has password
}
class Investor {
That's redundant. Hold on a sec...
class User {
- has id,
- has name,
- has password
+ has id,
+ has name,
+ has password
}
class Investor extends User {
Good idea, but how to put this into code?
-One far-too common and absolutely horrendous solution is to have a "checkbox" in your database: a nullable "investor" column, which entails a nullable "dollars" column, in the user table.
+One far-too common and absolutely horrendous solution is to have a "checkbox"
+in your database: a nullable "investor" column, which entails a nullable
+"dollars" column, in the user table.
create table "user" (
"id" integer not null primary key autoincrement,
Let's not discuss that further.
-A second, better, solution is to break out the two tables into user and investor:
+A second, better, solution is to break out the two tables into user and
+investor:
create table "user" (
"id" integer not null primary key autoincrement,
"dollars" integer
);
-So that investor's PK is just an FK to the user. We can clearly see the class hierarchy here, in which investor is a subclass of user. In DBIx::Class applications, this second strategy looks like:
+So that investor's PK is just an FK to the user. We can clearly see the class
+hierarchy here, in which investor is a subclass of user. In DBIx::Class
+applications, this second strategy looks like:
my $user_rs = $schema->resultset('User');
my $new_user = $user_rs->create(
dollars => $args->{dollars},
);
-One can cope well with the second strategy, and it seems to be the most popular smart choice.
-
+One can cope well with the second strategy, and it seems to be the most popular
+smart choice.
=head1 HOW?
-There is a third strategy implemented here. Make the database do more of the work: hide the nasty bits so we don't have to handle them unless we really want to. It'll save us some typing and it'll make for more expressive code. What if we could do this:
+There is a third strategy implemented here. Make the database do more of the
+work: hide the nasty bits so we don't have to handle them unless we really want
+to. It'll save us some typing and it'll make for more expressive code. What if
+we could do this:
my $new_investor = $schema->resultset('Investor')->create(
name => $args->{name},
password => $args->{password},
}
-should be created behind the scenes, and the use of either user or investor in your code should require no special handling. Deleting and updating $new_investor should also delete or update the user row.
+should be created behind the scenes, and the use of either user or investor
+in your code should require no special handling. Deleting and updating
+$new_investor should also delete or update the user row.
-It does. User and investor are both views, their concrete tables abstracted away behind a set of rules and triggers. You would expect the above DBIC create statement to look like this in SQL:
+It does. User and investor are both views, their concrete tables abstracted
+away behind a set of rules and triggers. You would expect the above DBIC
+create statement to look like this in SQL:
INSERT INTO investor ("name","password","dollars") VALUES (...);
INSERT INTO _user_table ("username","password") VALUES (...);
INSERT INTO _investor_table ("id","dollars") VALUES (currval('_user_table_id_seq',...) );
-For deletes, the triggers fire in reverse, to preserve referential integrity (foreign key constraints). For instance:
+For deletes, the triggers fire in reverse, to preserve referential integrity
+(foreign key constraints). For instance:
my $investor = $schema->resultset('Investor')->find({id => $args->{id}});
$investor->delete;
=item new
-MTI find the parents, if any, of your resultset class and adds them to the list of parent_sources for the table.
+MTI find the parents, if any, of your resultset class and adds them to the
+list of parent_sources for the table.
=item add_additional_parents
=item attach_additional_sources
-MTI takes the parents' sources and relationships, creates new DBIx::Class:Table object from them, and registers this as a new, raw, source in the schema, e.g.,
+MTI takes the parents' sources and relationships, creates a new
+DBIx::Class::Table object from them, and registers this as a new, raw, source
+in the schema, e.g.,
use MyApp::Schema;
=head2 CONTRIBUTORS
-Docs: Amiri Barksdale, E<lt>amiri@metalabel.comE<gt>
+Amiri Barksdale, E<lt>amiri@metalabel.comE<gt>
+
+=head1 COPYRIGHT
+
+Copyright (c) 2010 the DBIx::Class::ResultSource::MultipleTableInheritance
+L</AUTHOR> and L</CONTRIBUTORS> as listed above.
=head1 LICENSE
projects / dbsrgits/DBIx-Class-ResultSource-MultipleTableInheritance.git / commitdiff