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 you to set up relationships and perform joins on them.
+This class provides methods to set up relationships between the tables
+in your database model. Relationships are the most useful and powerful
+technique that L<DBIx::Class> provides. To create efficient database queries,
+create relationships between any and all tables that have something in
+common, for example if you have a table Authors:
+
+ ID | Name | Age
+ ------------------
+ 1 | Fred | 30
+ 2 | Joe | 32
+
+and a table Books:
+
+ ID | Author | Name
+ --------------------
+ 1 | 1 | Rulers of the universe
+ 2 | 1 | Rulers of the galaxy
+
+Then without relationships, the method of getting all books by Fred goes like
+this:
+
+ my $fred = $schema->resultset('Author')->find({ Name => 'Fred' });
+ my $fredsbooks = $schema->resultset('Book')->search({ Author => $fred->ID });
+With a has_many relationship called "books" on Author (see below for details),
+we can do this instead:
+
+ my $fredsbooks = $schema->resultset('Author')->find({ Name => 'Fred' })->books;
+
+Each relationship sets up an accessor method on the
+L<DBIx::Class::Manual::Glossary/"Row"> objects that represent the items
+of your table. From L<DBIx::Class::Manual::Glossary/"ResultSet"> objects,
+the relationships can be searched using the "search_related" method.
+In list context, each returns a list of Row objects for the related class,
+in scalar context, a new ResultSet representing the joined tables is
+returned. Thus, the calls can be chained to produce complex queries.
+Since the database is not actually queried until you attempt to retrieve
+the data for an actual item, no time is wasted producing them.
+
+ my $cheapfredbooks = $schema->resultset('Author')->find({
+ Name => 'Fred',
+ })->books->search_related('prices', {
+ Price => { '<=' => '5.00' },
+ });
+
+will produce a query something like:
+
+ SELECT * FROM Author me
+ LEFT JOIN Books books ON books.author = me.id
+ LEFT JOIN Prices prices ON prices.book = books.id
+ WHERE prices.Price <= 5.00
+
+all without needing multiple fetches.
Only the helper methods for setting up standard relationship types
are documented here. For the basic, lower-level methods, see
=head2 belongs_to
- # in a Bar class (where Foo has many Bars)
- __PACKAGE__->belongs_to(foo => Foo);
- my $f_obj = $obj->foo;
- $obj->foo($new_f_obj);
+ # in a Book class (where Author has many Books)
+ My::DBIC::Schema::Book->belongs_to(author => 'Author');
+ my $author_obj = $obj->author;
+ $obj->author($new_author_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
=head2 has_many
- # 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;
+ # in an Author class (where Author has many Books)
+ My::DBIC::Schema::Author->has_many(books => 'Book', 'author');
+ my $booklist = $obj->books;
+ my $booklist = $obj->books({
+ name => { LIKE => '%macaroni%' },
+ { prefetch => [qw/book/],
+ });
+ my @book_objs = $obj->books;
- $obj->add_to_foo(\%col_data);
+ $obj->add_to_books(\%col_data);
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
=head2 might_have
- __PACKAGE__->might_have(baz => Baz);
- my $f_obj = $obj->baz; # to get the baz object
+ My::DBIC::Schema::Author->might_have(psuedonym => 'Psuedonyms');
+ my $pname = $obj->psuedonym; # to get the Psuedonym object
-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.
+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.
-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.
+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 behaviour.
=head2 has_one
- __PACKAGE__->has_one(gorch => Gorch);
- my $f_obj = $obj->gorch;
+ My::DBIC::Schema::Book->has_one(isbn => ISBN);
+ my $isbn_obj = $obj->isbn;
+
+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 difference 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.
+
+
+=head2 many_to_many
+
+ My::DBIC::Schema::Actor->many_to_many( roles => 'actor_roles', 'Roles' );
-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 @role_objs = $actor->roles;
-=head2 many_to_many
-
- __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
projects / dbsrgits/DBIx-Class.git / blobdiff