use strict;
use warnings;
-use base qw/DBIx::Class Class::Data::Inheritable/;
+use base qw/DBIx::Class/;
__PACKAGE__->load_own_components(qw/
- HasMany
- HasOne
- BelongsTo
+ Helpers
Accessor
CascadeActions
ProxyMethods
Base
/);
-__PACKAGE__->mk_classdata('_relationships', { } );
-
=head1 NAME
DBIx::Class::Relationship - Inter-table relationships
=head1 DESCRIPTION
This class handles relationships between the tables in your database
-model. It allows your to set up relationships, and to perform joins
-on searches.
+model. It allows you to set up relationships and perform joins on them.
-This POD details only the convenience methods for setting up standard
-relationship types. For more information see ::Relationship::Base
+Only the helper methods for setting up standard relationship types
+are documented here. For the basic, lower-level methods, see
+L<DBIx::Class::Relationship::Base>.
=head1 METHODS
-All convenience methods take a signature of the following format -
+All helper methods take the following arguments:
+
+ __PACKAGE__>$method_name('relname', 'Foreign::Class', $cond, $attrs);
+
+Both C<$cond> and C<$attrs> are optional. Pass C<undef> for C<$cond> if
+you want to use the default value for it, but still want to set C<$attrs>.
+See L<DBIx::Class::Relationship::Base> for a list of valid attributes.
+
+=head2 belongs_to
- __PACKAGE__>method_name('relname', 'Foreign::Class', $join?, $attrs?);
+ # in a Bar class (where Foo has many Bars)
+ __PACKAGE__->belongs_to(foo => Foo);
+ my $f_obj = $obj->foo;
+ $obj->foo($new_f_obj);
+Creates a relationship where the calling class stores the foreign class's
+primary key in one (or more) of its columns. If $cond is a column name
+instead of a join condition hash, that is used as the name of the column
+holding the foreign key. If $cond is not given, the relname is used as
+the column name.
+NOTE: If you are used to L<Class::DBI> relationships, this is the equivalent
+of C<has_a>.
-=over 4
+=head2 has_many
-=item has_one
+ # in a Foo class (where Foo has many Bars)
+ __PACKAGE__->has_many(bar => Bar, 'foo');
+ my $f_resultset = $obj->foo;
+ my $f_resultset = $obj->foo({ name => { LIKE => '%macaroni%' }, { prefetch => [qw/bar/] });
+ my @f_obj = $obj->foo;
- my $f_obj = $obj->relname;
+ $obj->add_to_foo(\%col_data);
-Creates a one-one relationship with another class; defaults to PK-PK for
-the join condition unless a condition is specified.
+Creates a one-to-many relationship, where the corresponding elements of the
+foreign class store the calling class's primary key in one (or more) of its
+columns. You should pass the name of the column in the foreign class as the
+$cond argument, or specify a complete join condition.
-=item might_have
+If you delete an object in a class with a C<has_many> relationship, all
+related objects will be deleted as well. However, any database-level
+cascade or restrict will take precedence.
- my $f_obj = $obj->relname;
+=head2 might_have
-Creates an optional one-one relationship with another class; defaults to PK-PK
-for the join condition unless a condition is specified.
+ __PACKAGE__->might_have(baz => Baz);
+ my $f_obj = $obj->baz; # to get the baz object
-=item has_many
+Creates an optional one-to-one relationship with a class, where the foreign class
+stores our primary key in one of its columns. Defaults to the primary key of the
+foreign class unless $cond specifies a column or join condition.
- my @f_obj = $obj->relname($cond?, $attrs?);
- my $f_result_set = $obj->relname($cond?, $attrs?);
+If you update or delete an object in a class with a C<might_have> relationship,
+the related object will be updated or deleted as well. Any database-level update
+or delete constraints will override this behavior.
- $obj->add_to_relname(\%col_data);
+=head2 has_one
-Creates a one-many relationship with another class;
+ __PACKAGE__->has_one(gorch => Gorch);
+ my $f_obj = $obj->gorch;
-=item belongs_to
+Creates a one-to-one relationship with another class. This is just like C<might_have>,
+except the implication is that the other object is always present. The only different
+between C<has_one> and C<might_have> is that C<has_one> uses an (ordinary) inner join,
+whereas C<might_have> uses a left join.
- my $f_obj = $obj->relname;
- $obj->relname($new_f_obj);
+=head2 many_to_many
-Creates a relationship where we store the foreign class' PK; if $join is a
-column name instead of a condition that is assumed to be the FK, if not
-has_many assumes the FK is the relname is that is a column on the current
-class.
+ __PACKAGE__->many_to_many( 'accessorname' => 'a_to_b', 'table_b' );
+ my @f_objs = $obj_a->accessorname;
+
+Creates an accessor bridging two relationships; not strictly a relationship
+in its own right, although the accessor will return a resultset or collection
+of objects just as a has_many would.
=cut
1;
-=back
-
=head1 AUTHORS
Matt S. Trout <mst@shadowcatsystems.co.uk>
projects / dbsrgits/DBIx-Class.git / blobdiff