Skip site navigation (1)Skip section navigation (2)

FreeBSD Manual Pages

  
 
  

home | help
Rose::DB::Object::MetaUsereContributedtPerltDocumentatitionship::ManyToMany(3)

NAME
       Rose::DB::Object::Metadata::Relationship::ManyToMany - Many to many
       table relationship metadata object.

SYNOPSIS
	 use Rose::DB::Object::Metadata::Relationship::ManyToMany;

	 $rel =	Rose::DB::Object::Metadata::Relationship::ManyToMany->new(...);
	 $rel->make_methods(...);
	 ...

DESCRIPTION
       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.

EXAMPLE
       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')

METHOD MAP
       "count"
	   Rose::DB::Object::MakeMethods::Generic, objects_by_map, "interface
	   => 'count'" ...

       "find"
	   Rose::DB::Object::MakeMethods::Generic, objects_by_map, "interface
	   => 'find'" ...

       "iterator"
	   Rose::DB::Object::MakeMethods::Generic, objects_by_map, "interface
	   => 'iterator'" ...

       "get_set"
	   Rose::DB::Object::MakeMethods::Generic, objects_by_map, "interface
	   => 'get_set'" ...

       "get_set_now"
	   Rose::DB::Object::MakeMethods::Generic, objects_by_map, "interface
	   => 'get_set_now'" ...

       "get_set_on_save"
	   Rose::DB::Object::MakeMethods::Generic, objects_by_map, "interface
	   => 'get_set_on_save'" ...

       "add_now"
	   Rose::DB::Object::MakeMethods::Generic, objects_by_map, "interface
	   => 'add_now'" ...

       "add_on_save"
	   Rose::DB::Object::MakeMethods::Generic, objects_by_map, "interface
	   => 'add_on_save'" ...

       See the Rose::DB::Object::Metadata::Relationship	documentation for an
       explanation of this method map.

CLASS METHODS
       default_auto_method_types [TYPES]
	   Get or set the default list of auto_method_types.   TYPES should be
	   a list of relationship method types.	 Returns the list of default
	   relationship	method types (in list context) or a reference to an
	   array of the	default	relationship method types (in scalar context).
	   The default list contains  "get_set_on_save"	and "add_on_save".

OBJECT METHODS
       build_method_name_for_type TYPE
	   Return a method name	for the	relationship method type TYPE.

	   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.

       is_singular
	   Returns false.

       manager_class [CLASS]
	   Get or set the name of the Rose::DB::Object::Manager-derived	class
	   that	the map_class will use to fetch	records.  The make_methods
	   method will use Rose::DB::Object::Manager if	this value is left
	   undefined.

       manager_method [METHOD]
	   Get or set the name of the manager_class class method to call when
	   fetching records.  The make_methods method will use get_objects if
	   this	value is left undefined.

       manager_count_method [METHOD]
	   Get or set the name of the manager_class class method to call when
	   counting objects.  The make_methods method will use
	   get_objects_count if	this value is left undefined.

       manager_iterator_method [METHOD]
	   Get or set the name of the manager_class class method to call when
	   creating an iterator.  The make_methods method will use
	   get_objects_iterator	if this	value is left undefined.

       manager_args [HASHREF]
	   Get or set a	reference to a hash of name/value arguments to pass to
	   the manager_method when fetching objects.  For example, this	can be
	   used	to enforce a particular	sort order for objects fetched via
	   this	relationship.  Modifying the example above:

	     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.

       map_class [CLASS]
	   Get or set the name of the Rose::DB::Object-derived class that
	   fronts the table that maps between the other	two tables.  This
	   class must have a foreign key and/or	"many to one" relationship for
	   each	of the two tables that it maps between.

	   In the example above, the map class is "WidgetColorMap".

       map_from	[NAME]
	   Get or set the name of the "many to one" relationship or foreign
	   key in map_class that points	to the object of the current class.
	   Setting this	value is only necessary	if the map class has more than
	   one foreign key or "many to one" relationship that points to	one of
	   the classes that it maps between.

	   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.

       map_to [NAME]
	   Get or set the name of the "many to one" relationship or foreign
	   key in map_class that points	to the "foreign" object	to be fetched.
	   Setting this	value is only necessary	if the map class has more than
	   one foreign key or "many to one" relationship that points to	one of
	   the classes that it maps between.

	   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.

       query_args [ARRAYREF]
	   Get or set a	reference to an	array of query arguments to add	to the
	   query passed	to the manager_method when fetching objects.

	   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.

       share_db	[BOOL]
	   Get or set a	boolean	flag that indicates whether or not all of the
	   classes involved in fetching	objects	via this relationship
	   (including the objects themselves) will share the same
	   Rose::DB-derived db object.	Defaults to true.

       type
	   Returns "many to many".

AUTHOR
       John C. Siracusa	(siracusa@gmail.com)

LICENSE
       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.

perl v5.24.1	       Rose::DB::Object::Metadata::Relationship::ManyToMany(3)

NAME | SYNOPSIS | DESCRIPTION | EXAMPLE | METHOD MAP | CLASS METHODS | OBJECT METHODS | AUTHOR | LICENSE

Want to link to this manual page? Use this URL:
<https://www.freebsd.org/cgi/man.cgi?query=Rose::DB::Object::Metadata::Relationship::ManyToMany&sektion=3&manpath=FreeBSD+12.0-RELEASE+and+Ports>

home | help