|get||A method that returns one or more objects from the related table.|
These methods make up the public interface to relationship method creation. There are, however, several protected methods which are used internally to implement the methods described above. (The word protected is used here in a vaguely C++ sense, meaning accessible to subclasses, but not to the public.) Subclasses will probably find it easier to override and/or call these protected methods in order to influence the behavior of the public method maker methods.
A Rose::DB::Object::Metadata::Relationship object delegates method creation to a Rose::Object::MakeMethods-derived class. Each Rose::Object::MakeMethods-derived class has its own set of method types, each of which takes it own set of arguments.
Using this system, four pieces of information are needed to create a method on behalf of a Rose::DB::Object::Metadata::Relationship-derived object:
|o||The <B>relationship method typeB> (e.g., get)|
|o||The <B>method maker classB> (e.g., Rose::DB::Object::MakeMethods::Generic)|
|o||The <B>method maker method typeB> (e.g., object_by_key)|
|o||The <B>method maker argumentsB> (e.g., interface => get)|
|get_set||Rose::DB::Object::MakeMethods::Generic, scalar, interface => get_set, ...|
|get||Rose::DB::Object::MakeMethods::Generic, object_by_key, ...|
The ... in the method maker arguments is meant to indicate that arguments have been omitted. Arguments that are common to all relationship method types are routinely omitted from the method map for the sake of brevity. If there are no interesting method maker arguments, then ... may appear by itself, as shown above.
The purpose of documenting the method map is to answer the question, What kind of method(s) will be created by this relationship object for a given method type? Given the method map, its possible to read the documentation for each method maker class to determine how methods of the specified type behave when passed the listed arguments.
To this end, each Rose::DB::Object::Metadata::Relationship-derived class in the Rose::DB::Object module distribution will list its method map in its documentation. This is a concise way to document the behavior that is specific to each relationship class, while omitting the common functionality (which is documented here, in the relationship base class).
Remember, the existence and behavior of the method map is really implementation detail. A relationship object is free to implement the public method-making interface however it wants, without regard to any conceptual or actual method map. It must then, of course, document what kinds of methods it makes for each of its method types, but it does not have to use a method map to do so.
<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 is empty.
<B>new PARAMSB> Constructs a new object based on PARAMS, where PARAMS are name/value pairs. Any object method is a valid parameter name.
<B>available_method_typesB> Returns the full list of relationship method types supported by this class. <B>auto_method_types [TYPES]B> Get or set the list of relationship method types that are automatically created when make_methods is called without an explicit list of relationship method types. The default list is determined by the default_auto_method_types class method. <B>build_method_name_for_type TYPEB> Return a method name for the relationship method type TYPE. Subclasses must override this method. The default implementation causes a fatal error if called. <B>class [CLASS]B> Get or set the name of the Rose::DB::Object-derived class that fronts the foreign table referenced by this relationship. <B>is_singularB> Returns true of the relationship may refer to more than one related object, false otherwise. For example, this method returns true for is_singular in Rose::DB::Object::Metadata::Relationship::OneToMany objects, but false for is_singular in Rose::DB::Object::Metadata::Relationship::ManyToOne objects.
Relationship subclasses must override this method and return an appropriate value.
<B>make_methods PARAMSB> Create object method used to manipulate objects in related tables. Any applicable column triggers are also added. PARAMS are name/value pairs. Valid PARAMS are:
preserve_existing BOOL Boolean flag that indicates whether or not to preserve existing methods in the case of a name conflict. replace_existing BOOL Boolean flag that indicates whether or not to replace existing methods in the case of a name conflict. target_class CLASS The class in which to make the method(s). If omitted, it defaults to the calling class. types ARRAYREF A reference to an array of relationship method types to be created. If omitted, it defaults to the list of relationship method types returned by auto_method_types.
If any of the methods could not be created for any reason, a fatal error will occur.
<B>methods MAPB> Set the list of auto_method_types and method names all at once. MAP should be a reference to a hash whose keys are method types and whose values are either undef or method names. If a value is undef, then the method name for that method type will be generated by calling build_method_name_for_type, as usual. Otherwise, the specified method name will be used. <B>method_types [TYPES]B> This method is an alias for the auto_method_types method. <B>method_name TYPE [, NAME]B> Get or set the name of the relationship method of type TYPE. <B>name [NAME]B> Get or set the name of the relationship. This name must be unique among all other relationships for a given Rose::DB::Object-derived class. <B>typeB> Returns a string describing the type of relationship. Subclasses must override this method. The default implementation causes a fatal error if called.
These methods are not part of the public interface, but are supported for use by subclasses. Put another way, given an unknown object that isa Rose::DB::Object::Metadata::Relationship, there should be no expectation that the following methods exist. But subclasses, which know the exact class from which they inherit, are free to use these methods in order to implement the public API described above.
<B>method_maker_arguments TYPEB> Returns a hash (in list context) or reference to a hash (in scalar context) of name/value arguments that will be passed to the method_maker_class when making the relationship method type TYPE. <B>method_maker_class TYPE [, CLASS]B> If CLASS is passed, the name of the Rose::Object::MakeMethods-derived class used to create the object method of type TYPE is set to CLASS.
Returns the name of the Rose::Object::MakeMethods-derived class used to create the object method of type TYPE.
<B>method_maker_type TYPE [, NAME]B> If NAME is passed, the name of the method maker method type for the relationship method type TYPE is set to NAME.
Returns the method maker method type for the relationship method type TYPE.
John C. Siracusa (email@example.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.
|perl v5.20.3||ROSE::DB::OBJECT::METADATA::RELATIONSHIP (3)||2015-03-17|