X-Git-Url: http://git.shadowcat.co.uk/gitweb/gitweb.cgi?a=blobdiff_plain;f=lib%2FDBIx%2FClass%2FRelationship.pm;h=0ee14aa8f13f8d004b65373b47c5a3ea1e033f71;hb=a361b76d7967061cdc84cea6801674c458971809;hp=e9adb82de3059eb457c7dac0f8983e430d88060c;hpb=87c4e6021744dca313843a87b876c1845b72729d;p=dbsrgits%2FDBIx-Class.git diff --git a/lib/DBIx/Class/Relationship.pm b/lib/DBIx/Class/Relationship.pm index e9adb82..0ee14aa 100644 --- a/lib/DBIx/Class/Relationship.pm +++ b/lib/DBIx/Class/Relationship.pm @@ -21,8 +21,54 @@ 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 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 objects that represent the items +of your table. From L 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 @@ -40,10 +86,10 @@ See L for a list of valid attributes. =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 @@ -56,13 +102,13 @@ of C. =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 @@ -75,32 +121,37 @@ cascade or restrict will take precedence. =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 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 +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, -except the implication is that the other object is always present. The only different -between C and C is that C uses an (ordinary) inner join, -whereas C uses a left join. +Creates a one-to-one relationship with another class. This is just like +C, except the implication is that the other object is always +present. The only difference between C and C is that +C uses an (ordinary) inner join, whereas C uses a +left join. =head2 many_to_many - __PACKAGE__->many_to_many( 'accessorname' => 'a_to_b', 'table_b' ); - my @f_objs = $obj_a->accessorname; + My::DBIC::Schema::Actor->many_to_many( roles => 'actor_roles', 'Roles' ); + my @role_objs = $obj_a->roles; + +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