| Rose::DB::Object::Metadata::Relationship::ManyToMany(3pm) | User Contributed Perl Documentation | Rose::DB::Object::Metadata::Relationship::ManyToMany(3pm) |
Rose::DB::Object::Metadata::Relationship::ManyToMany - Many to many table relationship metadata object.
use Rose::DB::Object::Metadata::Relationship::ManyToMany; $rel = Rose::DB::Object::Metadata::Relationship::ManyToMany->new(...); $rel->make_methods(...); ...
Objects of this class store and manipulate metadata for relationships in which rows from one table are connected to rows in another table through an intermediate table that maps between them.
This class inherits from Rose::DB::Object::Metadata::Relationship. Inherited methods that are not overridden will not be documented a second time here. See the Rose::DB::Object::Metadata::Relationship documentation for more information.
Consider the following tables.
CREATE TABLE widgets
(
id SERIAL PRIMARY KEY,
name VARCHAR(255)
);
CREATE TABLE colors
(
id SERIAL PRIMARY KEY,
name VARCHAR(255)
);
CREATE TABLE widget_color_map
(
id SERIAL PRIMARY KEY,
widget_id INT NOT NULL REFERENCES widgets (id),
color_id INT NOT NULL REFERENCES colors (id),
UNIQUE(widget_id, color_id)
);
Given these tables, each widget can have zero or more colors, and each color can be applied to zero or more widgets. This is the type of "many to many" relationship that this class is designed to handle.
In order to do so, each of the three of the tables that participate in the relationship must be fronted by its own Rose::DB::Object-derived class. Let's call those classes "Widget", "Color", and "WidgetColorMap".
The class that maps between the other two classes is called the "map class." In this example, it's "WidgetColorMap". The map class must have a foreign key and/or "many to one" relationship pointing to each of the two classes that it maps between.
When it comes to actually creating the three classes that participate in a "many to many" relationship, there's a bit of a "chicken and egg" problem. All these classes need to know about each other more or less "simultaneously," but they must be defined in a serial fashion, and may be loaded in any order by the user.
In order to account for this, method creation may be deferred for any foreign key or relationship that does not yet have all the information it requires to do its job. This should be transparent to the developer.
Here's a complete example using the "Widget", "Color", and "WidgetColorMap" classes. First, the "Widget" class which has a "many to many" relationship through which it can retrieve its colors.
package Widget;
use base 'Rose::DB::Object';
__PACKAGE__->meta->setup
(
table => 'widgets',
columns =>
[
id => { type => 'int', primary_key => 1 },
name => { type => 'varchar', length => 255 },
],
relationships =>
[
# Define "many to many" relationship to get colors
colors =>
{
type => 'many to many',
map_class => 'WidgetColorMap',
# These are only necessary if the relationship is ambiguous
#map_from => 'widget',
#map_to => 'color',
},
],
);
1;
Next, the "Color" class which has a "many to many" relationship through which it can retrieve all the widgets that have this color.
package Color;
use base 'Rose::DB::Object';
__PACKAGE__->meta->setup
(
table => 'colors',
columns =>
[
id => { type => 'int', primary_key => 1 },
name => { type => 'varchar', length => 255 },
],
relationships =>
[
# Define "many to many" relationship to get widgets
widgets =>
{
type => 'many to many',
map_class => 'WidgetColorMap',
# These are only necessary if the relationship is ambiguous
#map_from => 'color',
#map_to => 'widget',
},
],
);
1;
Finally, the "WidgetColorMap" class must have a foreign key or "many to one" relationship for each of the two classes that it maps between ("Widget" and "Color").
package WidgetColorMap;
use base 'Rose::DB::Object';
__PACKAGE__->meta->setup
(
table => 'widget_color_map',
columns =>
[
id => { type => 'int', primary_key => 1 },
widget_id => { type => 'int' },
color_id => { type => 'int' },
],
foreign_keys =>
[
# Define foreign keys that point to each of the two classes
# that this class maps between.
color =>
{
class => 'Color',
key_columns => { color_id => 'id' },
},
widget =>
{
class => 'Widget',
key_columns => { widget_id => 'id' },
},
],
);
1;
Here's an initial set of data and some examples of the above classes in action. First, the data:
INSERT INTO widgets (id, name) VALUES (1, 'Sprocket'); INSERT INTO widgets (id, name) VALUES (2, 'Flange'); INSERT INTO colors (id, name) VALUES (1, 'Red'); INSERT INTO colors (id, name) VALUES (2, 'Green'); INSERT INTO colors (id, name) VALUES (3, 'Blue'); INSERT INTO widget_color_map (widget_id, color_id) VALUES (1, 1); INSERT INTO widget_color_map (widget_id, color_id) VALUES (1, 2); INSERT INTO widget_color_map (widget_id, color_id) VALUES (2, 3);
Now the code:
use Widget;
use Color;
$widget = Widget->new(id => 1);
$widget->load;
@colors = map { $_->name } $widget->colors; # ('Red', 'Green')
$color = Color->new(id => 1);
$color->load;
@widgets = map { $_->name } $color->widgets; # ('Sprocket')
See the Rose::DB::Object::Metadata::Relationship documentation for an explanation of this method map.
For the method types "get_set", "get_set_now", and "get_set_on_save", the relationship's name is returned.
For the method types "add_now" and "add_on_save", the relationship's name prefixed with "add_" is returned.
For the method type "find", the relationship's name prefixed with "find_" is returned.
For the method type "count", the relationship's name suffixed with "_count" is returned.
For the method type "iterator", the relationship's name suffixed with "_iterator" is returned.
Otherwise, undef is returned.
Widget->meta->add_relationship
(
colors =>
{
type => 'many to many',
map_class => 'WidgetColorMap',
manager_args => { sort_by => Color->meta->table . '.name' },
},
);
This would ensure that a "Widget"'s "colors()" are listed in alphabetical order. Note that the "name" column is prefixed by the name of the table fronted by the "Color" class. This is important because several tables may have a column named "name." If this relationship is used to form a JOIN in a query along with one of those tables, then the "name" column will be ambiguous. Adding a table name prefix disambiguates the column name.
Also note that the table name is not hard-coded. Instead, it is fetched from the Rose::DB::Object-derived class that fronts the table. This is more verbose, but is a much better choice than including the literal table name when it comes to long-term maintenance of the code.
See the documentation for Rose::DB::Object::Manager's get_objects method for a full list of valid arguments for use with the "manager_args" parameter, but remember that you can define your own custom manager_class and thus can also define what kinds of arguments "manager_args" will accept.
Note: when the name of a relationship that has "manager_args" is used in a Rose::DB::Object::Manager with_objects or require_objects parameter value, only the sort_by argument will be copied from "manager_args" and incorporated into the query.
In the example above, the map class is "WidgetColorMap".
In the example above, the value of map_from would be "widget" when defining the "many to many" relationship in the "Widget" class, or "color" when defining the "many to many" relationship in the "Color" class. Neither of these settings is necessary in the example because the "WidgetColorMap" class has one foreign key that points to each class, so there is no ambiguity.
In the example above, the value of map_from would be "color" when defining the "many to many" relationship in the "Widget" class, or "widget" when defining the "many to many" relationship in the "Color" class. Neither of these settings is necessary in the example because the "WidgetColorMap" class has one foreign key that points to each class, so there is no ambiguity.
This can be used to limit the objects fetched via this relationship. For example, modifying the example above:
Widget->meta->add_relationship
(
colors =>
{
type => 'many to many',
map_class => 'WidgetColorMap',
query_args => [ name => { like => '%e%' } ],
},
);
See the documentation for Rose::DB::Object::Manager's get_objects method for a full list of valid "query" arguments.
John C. Siracusa (siracusa@gmail.com)
Copyright (c) 2010 by John C. Siracusa. All rights reserved. This program is free software; you can redistribute it and/or modify it under the same terms as Perl itself.
| 2020-06-21 | perl v5.30.3 |