DBIx-Class-ResultSource-MultipleTableInheritance
view release on metacpan or search on metacpan
print STDERR Dwarn $cup->result_source->columns;
"id"
"flavor"
"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
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.
WHY?
In many applications, many classes are subclasses of others. Let's say
you have this schema:
# Conceptual domain model
README.html view on Meta::CPAN
<pre>
my $cup = $schema->resultset('Sumatra');</pre>
<pre>
print STDERR Dwarn $cup->result_source->columns;</pre>
<pre>
"id"
"flavor"
"aroma"
..</pre>
<p>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 <strong>transparently
writable</strong>.</p>
<p>This is accomplished through the use of stored procedures that map changes
written to the view to changes to the underlying concrete tables.</p>
<p>
</p>
<hr />
<h1><a name="why">WHY?</a></h1>
<p>In many applications, many classes are subclasses of others. Let's say you
have this schema:</p>
<pre>
lib/DBIx/Class/ResultSource/MultipleTableInheritance.pm view on Meta::CPAN
my $cup = $schema->resultset('Sumatra');
print STDERR Dwarn $cup->result_source->columns;
"id"
"flavor"
"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.
=head1 WHY?
In many applications, many classes are subclasses of others. Let's say you
have this schema:
( run in 0.503 second using v1.01-cache-2.11-cpan-0a6323c29d9 )