GSP
Quick Navigator

Search Site

Unix VPS
A - Starter
B - Basic
C - Preferred
D - Commercial
MPS - Dedicated
Previous VPSs
* Sign Up! *

Support
Contact Us
Online Help
Handbooks
Domain Status
Man Pages

FAQ
Virtual Servers
Pricing
Billing
Technical

Network
Facilities
Connectivity
Topology Map

Miscellaneous
Server Agreement
Year 2038
Credits
 

USA Flag

 

 

Man Pages


Manual Reference Pages  -  ROSE::DB::OBJECT::METADATA::RELATIONSHIP::MANYTOMANY (3)

.ds Aq ’

NAME

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

CONTENTS

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 <B>mustB> 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

<B>default_auto_method_types [TYPES]B> 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

<B>build_method_name_for_type TYPEB> 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.

<B>is_singularB> Returns false.
<B>manager_class [CLASS]B> 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.
<B>manager_method [METHOD]B> 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.
<B>manager_count_method [METHOD]B> 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.
<B>manager_iterator_method [METHOD]B> 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.
<B>manager_args [HASHREF]B> 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.

<B>Note:B> 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.

<B>map_class [CLASS]B> 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.

<B>map_from [NAME]B> 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.

<B>map_to [NAME]B> 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.

<B>query_args [ARRAYREF]B> 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.

<B>share_db [BOOL]B> 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.
<B>typeB> 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.
Search for    or go to Top of page |  Section 3 |  Main Index


perl v5.20.3 ROSE::DB::OBJECT::METADATA::RELATIONSHIP::MANYTOMANY (3) 2015-03-17

Powered by GSP Visit the GSP FreeBSD Man Page Interface.
Output converted with manServer 1.07.