1Rose::DB::Object::MetadUasRteoars:e:C:Ro:enDltBar:ti:ibOoubntjseehdcitpP::e::rMMleatnDayodTcaoutMmaae:nn:ytR(ae3tl)iaotnionship::ManyToMany(3)
2
6 Rose::DB::Object::Metadata::Relationship::ManyToMany - Many to many
7 table relationship metadata object.
8
10 use Rose::DB::Object::Metadata::Relationship::ManyToMany;
11 $rel = Rose::DB::Object::Metadata::Relationship::ManyToMany->new(...);
13 $rel->make_methods(...);
14 ...
15
17 Objects of this class store and manipulate metadata for relationships
18 in which rows from one table are connected to rows in another table
19 through an intermediate table that maps between them.
20 This class inherits from Rose::DB::Object::Metadata::Relationship.
22 Inherited methods that are not overridden will not be documented a
23 second time here. See the Rose::DB::Object::Metadata::Relationship
24 documentation for more information.
25
27 Consider the following tables.
28 CREATE TABLE widgets
30 (
31 id SERIAL PRIMARY KEY,
32 name VARCHAR(255)
33 );
34 CREATE TABLE colors
36 (
37 id SERIAL PRIMARY KEY,
38 name VARCHAR(255)
39 );
40 CREATE TABLE widget_color_map
42 (
43 id SERIAL PRIMARY KEY,
44 widget_id INT NOT NULL REFERENCES widgets (id),
45 color_id INT NOT NULL REFERENCES colors (id),
46 UNIQUE(widget_id, color_id)
47 );
48 Given these tables, each widget can have zero or more colors, and each
50 color can be applied to zero or more widgets. This is the type of
51 "many to many" relationship that this class is designed to handle.
52 In order to do so, each of the three of the tables that participate in
54 the relationship must be fronted by its own Rose::DB::Object-derived
55 class. Let's call those classes "Widget", "Color", and
56 "WidgetColorMap".
57 The class that maps between the other two classes is called the "map
59 class." In this example, it's "WidgetColorMap". The map class must
60 have a foreign key and/or "many to one" relationship pointing to each
61 of the two classes that it maps between.
62 When it comes to actually creating the three classes that participate
64 in a "many to many" relationship, there's a bit of a "chicken and egg"
65 problem. All these classes need to know about each other more or less
66 "simultaneously," but they must be defined in a serial fashion, and may
67 be loaded in any order by the user.
68 In order to account for this, method creation may be deferred for any
70 foreign key or relationship that does not yet have all the information
71 it requires to do its job. This should be transparent to the
72 developer.
73 Here's a complete example using the "Widget", "Color", and
75 "WidgetColorMap" classes. First, the "Widget" class which has a "many
76 to many" relationship through which it can retrieve its colors.
77 package Widget;
79 use base 'Rose::DB::Object';
81 __PACKAGE__->meta->setup
83 (
84 table => 'widgets',
85 columns =>
87 [
88 id => { type => 'int', primary_key => 1 },
89 name => { type => 'varchar', length => 255 },
90 ],
91 relationships =>
93 [
94 # Define "many to many" relationship to get colors
95 colors =>
96 {
97 type => 'many to many',
98 map_class => 'WidgetColorMap',
99 # These are only necessary if the relationship is ambiguous
101 #map_from => 'widget',
102 #map_to => 'color',
103 },
104 ],
105 );
106 1;
108 Next, the "Color" class which has a "many to many" relationship through
110 which it can retrieve all the widgets that have this color.
111 package Color;
113 use base 'Rose::DB::Object';
115 __PACKAGE__->meta->setup
117 (
118 table => 'colors',
119 columns =>
121 [
122 id => { type => 'int', primary_key => 1 },
123 name => { type => 'varchar', length => 255 },
124 ],
125 relationships =>
127 [
128 # Define "many to many" relationship to get widgets
129 widgets =>
130 {
131 type => 'many to many',
132 map_class => 'WidgetColorMap',
133 # These are only necessary if the relationship is ambiguous
135 #map_from => 'color',
136 #map_to => 'widget',
137 },
138 ],
139 );
140 1;
142 Finally, the "WidgetColorMap" class must have a foreign key or "many to
144 one" relationship for each of the two classes that it maps between
145 ("Widget" and "Color").
146 package WidgetColorMap;
148 use base 'Rose::DB::Object';
150 __PACKAGE__->meta->setup
152 (
153 table => 'widget_color_map',
154 columns =>
156 [
157 id => { type => 'int', primary_key => 1 },
158 widget_id => { type => 'int' },
159 color_id => { type => 'int' },
160 ],
161 foreign_keys =>
163 [
164 # Define foreign keys that point to each of the two classes
165 # that this class maps between.
166 color =>
167 {
168 class => 'Color',
169 key_columns => { color_id => 'id' },
170 },
171 widget =>
173 {
174 class => 'Widget',
175 key_columns => { widget_id => 'id' },
176 },
177 ],
178 );
179 1;
181 Here's an initial set of data and some examples of the above classes in
183 action. First, the data:
184 INSERT INTO widgets (id, name) VALUES (1, 'Sprocket');
186 INSERT INTO widgets (id, name) VALUES (2, 'Flange');
187 INSERT INTO colors (id, name) VALUES (1, 'Red');
189 INSERT INTO colors (id, name) VALUES (2, 'Green');
190 INSERT INTO colors (id, name) VALUES (3, 'Blue');
191 INSERT INTO widget_color_map (widget_id, color_id) VALUES (1, 1);
193 INSERT INTO widget_color_map (widget_id, color_id) VALUES (1, 2);
194 INSERT INTO widget_color_map (widget_id, color_id) VALUES (2, 3);
195 Now the code:
197 use Widget;
199 use Color;
200 $widget = Widget->new(id => 1);
202 $widget->load;
203 @colors = map { $_->name } $widget->colors; # ('Red', 'Green')
205 $color = Color->new(id => 1);
207 $color->load;
208 @widgets = map { $_->name } $color->widgets; # ('Sprocket')
210
212 "count"
213 Rose::DB::Object::MakeMethods::Generic, objects_by_map, "interface
214 => 'count'" ...
215 "find"
217 Rose::DB::Object::MakeMethods::Generic, objects_by_map, "interface
218 => 'find'" ...
219 "iterator"
221 Rose::DB::Object::MakeMethods::Generic, objects_by_map, "interface
222 => 'iterator'" ...
223 "get_set"
225 Rose::DB::Object::MakeMethods::Generic, objects_by_map, "interface
226 => 'get_set'" ...
227 "get_set_now"
229 Rose::DB::Object::MakeMethods::Generic, objects_by_map, "interface
230 => 'get_set_now'" ...
231 "get_set_on_save"
233 Rose::DB::Object::MakeMethods::Generic, objects_by_map, "interface
234 => 'get_set_on_save'" ...
235 "add_now"
237 Rose::DB::Object::MakeMethods::Generic, objects_by_map, "interface
238 => 'add_now'" ...
239 "add_on_save"
241 Rose::DB::Object::MakeMethods::Generic, objects_by_map, "interface
242 => 'add_on_save'" ...
243 See the Rose::DB::Object::Metadata::Relationship documentation for an
245 explanation of this method map.
246
248 default_auto_method_types [TYPES]
249 Get or set the default list of auto_method_types. TYPES should be
250 a list of relationship method types. Returns the list of default
251 relationship method types (in list context) or a reference to an
252 array of the default relationship method types (in scalar context).
253 The default list contains "get_set_on_save" and "add_on_save".
254
256 build_method_name_for_type TYPE
257 Return a method name for the relationship method type TYPE.
258 For the method types "get_set", "get_set_now", and
260 "get_set_on_save", the relationship's name is returned.
261 For the method types "add_now" and "add_on_save", the
263 relationship's name prefixed with "add_" is returned.
264 For the method type "find", the relationship's name prefixed with
266 "find_" is returned.
267 For the method type "count", the relationship's name suffixed with
269 "_count" is returned.
270 For the method type "iterator", the relationship's name suffixed
272 with "_iterator" is returned.
273 Otherwise, undef is returned.
275 is_singular
277 Returns false.
278 manager_class [CLASS]
280 Get or set the name of the Rose::DB::Object::Manager-derived class
281 that the map_class will use to fetch records. The make_methods
282 method will use Rose::DB::Object::Manager if this value is left
283 undefined.
284 manager_method [METHOD]
286 Get or set the name of the manager_class class method to call when
287 fetching records. The make_methods method will use get_objects if
288 this value is left undefined.
289 manager_count_method [METHOD]
291 Get or set the name of the manager_class class method to call when
292 counting objects. The make_methods method will use
293 get_objects_count if this value is left undefined.
294 manager_iterator_method [METHOD]
296 Get or set the name of the manager_class class method to call when
297 creating an iterator. The make_methods method will use
298 get_objects_iterator if this value is left undefined.
299 manager_args [HASHREF]
301 Get or set a reference to a hash of name/value arguments to pass to
302 the manager_method when fetching objects. For example, this can be
303 used to enforce a particular sort order for objects fetched via
304 this relationship. Modifying the example above:
305 Widget->meta->add_relationship
307 (
308 colors =>
309 {
310 type => 'many to many',
311 map_class => 'WidgetColorMap',
312 manager_args => { sort_by => Color->meta->table . '.name' },
313 },
314 );
315 This would ensure that a "Widget"'s "colors()" are listed in
317 alphabetical order. Note that the "name" column is prefixed by the
318 name of the table fronted by the "Color" class. This is important
319 because several tables may have a column named "name." If this
320 relationship is used to form a JOIN in a query along with one of
321 those tables, then the "name" column will be ambiguous. Adding a
322 table name prefix disambiguates the column name.
323 Also note that the table name is not hard-coded. Instead, it is
325 fetched from the Rose::DB::Object-derived class that fronts the
326 table. This is more verbose, but is a much better choice than
327 including the literal table name when it comes to long-term
328 maintenance of the code.
329 See the documentation for Rose::DB::Object::Manager's get_objects
331 method for a full list of valid arguments for use with the
332 "manager_args" parameter, but remember that you can define your own
333 custom manager_class and thus can also define what kinds of
334 arguments "manager_args" will accept.
335 Note: when the name of a relationship that has "manager_args" is
337 used in a Rose::DB::Object::Manager with_objects or require_objects
338 parameter value, only the sort_by argument will be copied from
339 "manager_args" and incorporated into the query.
340 map_class [CLASS]
342 Get or set the name of the Rose::DB::Object-derived class that
343 fronts the table that maps between the other two tables. This
344 class must have a foreign key and/or "many to one" relationship for
345 each of the two tables that it maps between.
346 In the example above, the map class is "WidgetColorMap".
348 map_from [NAME]
350 Get or set the name of the "many to one" relationship or foreign
351 key in map_class that points to the object of the current class.
352 Setting this value is only necessary if the map class has more than
353 one foreign key or "many to one" relationship that points to one of
354 the classes that it maps between.
355 In the example above, the value of map_from would be "widget" when
357 defining the "many to many" relationship in the "Widget" class, or
358 "color" when defining the "many to many" relationship in the
359 "Color" class. Neither of these settings is necessary in the
360 example because the "WidgetColorMap" class has one foreign key that
361 points to each class, so there is no ambiguity.
362 map_to [NAME]
364 Get or set the name of the "many to one" relationship or foreign
365 key in map_class that points to the "foreign" object to be fetched.
366 Setting this value is only necessary if the map class has more than
367 one foreign key or "many to one" relationship that points to one of
368 the classes that it maps between.
369 In the example above, the value of map_from would be "color" when
371 defining the "many to many" relationship in the "Widget" class, or
372 "widget" when defining the "many to many" relationship in the
373 "Color" class. Neither of these settings is necessary in the
374 example because the "WidgetColorMap" class has one foreign key that
375 points to each class, so there is no ambiguity.
376 query_args [ARRAYREF]
378 Get or set a reference to an array of query arguments to add to the
379 query passed to the manager_method when fetching objects.
380 This can be used to limit the objects fetched via this
382 relationship. For example, modifying the example above:
383 Widget->meta->add_relationship
385 (
386 colors =>
387 {
388 type => 'many to many',
389 map_class => 'WidgetColorMap',
390 query_args => [ name => { like => '%e%' } ],
391 },
392 );
393 See the documentation for Rose::DB::Object::Manager's get_objects
395 method for a full list of valid "query" arguments.
396 share_db [BOOL]
398 Get or set a boolean flag that indicates whether or not all of the
399 classes involved in fetching objects via this relationship
400 (including the objects themselves) will share the same
401 Rose::DB-derived db object. Defaults to true.
402 type
404 Returns "many to many".
405
407 John C. Siracusa (siracusa@gmail.com)
408
410 Copyright (c) 2010 by John C. Siracusa. All rights reserved. This
411 program is free software; you can redistribute it and/or modify it
412 under the same terms as Perl itself.
413perl v5.32.1 Rose::DB::O2b0j2e1c-t0:1:-M2e7tadata::Relationship::ManyToMany(3)