__PACKAGE__->mk_group_accessors(simple => qw(parent_source additional_parents));
+# how this works:
+#
+# On construction, we hook $self->result_class->result_source_instance
+# if present to get the superclass' source object
+#
+# When attached to a schema, we need to add sources to that schema with
+# appropriate relationships for the foreign keys so the concrete tables
+# get generated
+#
+# We also generate our own view definition using this class' concrete table
+# and the view for the superclass, and stored procedures for the insert,
+# update and delete operations on this view.
+#
+# deploying the postgres rules through SQLT may be a pain though.
+
method new ($class: @args) {
my $new = $class->next::method(@args);
my $rc = $new->result_class;
1;
__END__
-
-# how this works:
-#
-# On construction, we hook $self->result_class->result_source_instance
-# if present to get the superclass' source object
-#
-# When attached to a schema, we need to add sources to that schema with
-# appropriate relationships for the foreign keys so the concrete tables
-# get generated
-#
-# We also generate our own view definition using this class' concrete table
-# and the view for the superclass, and stored procedures for the insert,
-# update and delete operations on this view.
-#
-# deploying the postgres rules through SQLT may be a pain though.
-
-=encoding utf-8
-
=head1 NAME
DBIx::Class::ResultSource::MultipleTableInheritance -- Use multiple tables to define your classes
=head1 SYNOPSIS
-
{
package MyApp::Schema::Result::Coffee;
$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>.
-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<transparentlt writable>.
+This is accomplished through the use of stored procedures that map changes written to the view to changes to the underlying concrete tables.
-This is accomplished through the use of stored functions that map changes written to the view to changes to the underlying concrete tables.
=head1 WHY?
has password
}
- class Investor isa User {
+ class Investor extends User {
has dollars
}
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. 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},
dollars => $args->{dollars},
);
-And have it Just Work? The user ( {name => $args->{name}, password => $args->{password} } ) should be created transparently, 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.
+And have it Just Work? The user...
+
+ {
+ 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.
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:
DELETE FROM _user_table WHERE ("id" = ?);
-
+=head1 METHODS
+
+=over
+
+=item new
+
+
+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
+
+
+Continuing with coffee:
+
+ __PACKAGE__->result_source_instance->add_additional_parents(
+ qw/
+ MyApp::Schema::Result::Beverage
+ MyApp::Schema::Result::Liquid
+ /
+ );
+
+This just lets you manually add additional parents beyond the ones MTI finds.
+
+=item add_additional_parent
+
+ __PACKAGE__->result_source_instance->add_additional_parent(
+ MyApp::Schema::Result::Beverage
+ );
+
+You can also add just one.
+
+=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.,
+
+ use MyApp::Schema;
+
+ print STDERR map { "$_\n" } MyApp::Schema->sources;
+
+ # Coffee
+ # Beverage
+ # Liquid
+ # Sumatra
+ # Raw::Sumatra
+Raw::Sumatra will be used to generate the view.
+=item view_definition
+This takes the raw table and generates the view (and stored procedures) you will use.
+=back
=head1 AUTHOR
projects / dbsrgits/DBIx-Class-ResultSource-MultipleTableInheritance.git / blobdiff