Alzabo::MethodMaker - Auto-generate useful methods based on an existing schema
use Alzabo::MethodMaker ( schema => 'schema_name', all => 1 );
This module can take an existing schema and generate a number of useful methods for this schema and its tables and rows. The method making is controlled by the parameters given along with the use statement, as seen in the SYNOPSIS section.
This parameter is required.
If given, this will be used as the root of the class names generated by this module. This root should not end in '::'. If none is given, then the calling module's name is used as the root. See "Class Names" for more information.
This tells this module to make all of the methods it possibly can. See METHOD CREATION OPTIONS for more details.
If this option is given, then this callback will be called any time a method name needs to be generated. This allows you to have full control over the resulting names. Otherwise names are generated as described in the documentation.
The callback is expected to return a name for the method to be used. This name should not be fully qualified or contain any class designation as this will be handled by MethodMaker.
It is important that none of the names returned conflict with existing methods for the object the method is being added to.
For example, when adding methods that return column objects to a table, if you have a column called 'name' and try to use that as the method name, it won't work. Alzabo::Table objects already have such a method, which returns the name of the table. See the relevant documentation of the schema, table, and row objects for a list of methods they contain.
Alzabo::Table
The callback will receive a hash containing the following parameters:
type => $method_type
This will always be the same as one of the parameters you give to the import method. It will be one of the following: foreign_key, insert, linking_table, lookup_columns, row_column, self_relation, table, table_column, or update.
foreign_key
insert
linking_table
lookup_columns
row_column
self_relation
table
table_column
update
The following parameters vary from case to case:
When the type is table:
table => Alzabo::Table object
This parameter will be passed when the type is table. It is the table object the schema object's method will return.
When the type is table_column or row_column:
column => Alzabo::Column object
When the type is table_column, this is the column object the method will return. When the type is row_column, then it is the column whose value the method will return.
When the type is foreign_key, linking_table, or self_relation:
foreign_key => Alzabo::ForeignKey object
This is the foreign key on which the method is based.
When the type is foreign_key:
plural => $bool
This indicates whether or not the method that is being created will return a cursor object (true) or a row object (false).
When the type is linking_table:
foreign_key_2 => Alzabo::ForeignKey object
When making a linking table method, two foreign keys are used. The foreign_key is from the table being linked from to the linking table. This parameter is the foreign key from the linking table to the table being linked to.
When the type is lookup_columns:
When making lookup column methods, this column is the column in the foreign table for which a method is being made.
When the type is self_relation:
parent => $boolean
This indicates whether or not the method being created will return parent objects (true) or child objects (false).
Using this module has several effects on your schema's objects.
Using this module causes your schema, table, and row objects to be blessed into subclasses of Alzabo::Runtime::Schema, Alzabo::Runtime::Table, Alzabo::Runtime::Row, respectively. These subclasses contain the various methods created by this module. The new class names are formed by using the class_root parameter and adding to it.
Alzabo::Runtime::Schema
Alzabo::Runtime::Table
Alzabo::Runtime::Row
class_root
<class root>::Schema
<class root>::Table::<table name>
<class root>::Row::<table name>, subclassed by <class root>::CachedRow::<table name> and <class root>::UncachedRow::<table name>
<class root>::Row::<table name>
<class root>::CachedRow::<table name>
<class root>::UncachedRow::<table name>
With a root of 'My::Stuff', and a schema with only two tables, 'movie' and 'image', this would result in the following class names:
My::Stuff::Schema My::Stuff::Table::movie My::Stuff::Row::movie My::Stuff::CachedRow::movie My::Stuff::UncachedRow::movie My::Stuff::Table::image My::Stuff::Row::image My::Stuff::CachedRow::image My::Stuff::UncachedRow::image
For each class into which an object is blessed, this module will attempt to load that class via a use statement. If there is no module found this will not cause an error. If this class defines any methods that have the same name as those this module generates, then this module will not attempt to generate them.
use
validate_insert
validate_update
These methods can be defined in the relevant table and row class, respectively. If they are defined then they will be called before any actual inserts or updates are done.
The validate_update method should be defined in the <class root>::Row::<table name> class, not its subclasses.
They both should expect to receive a hash of column names to values as their parameters. For validate_insert, this will represent the new row to be inserted. For validate_update, this will represent the changes to the existing row.
These methods should throw exceptions if there are errors with this data.
For this to work, you must specify the insert and/or update parameters as true when loading the module. This causes these methods to be overridden in the generated subclasses.
When using Alzabo::MethodMaker, you may specify any of the following parameters. Specifying 'all' causes all of them to be used.
Creates methods for the schema that return the table object matching the name of the method.
For example, given a schema containing tables named 'movie' and 'image', this would create methods that could be called as $schema->movie and $schema->image.
$schema->movie
$schema->image
Creates methods for the tables that return the column object matching the name of the method. This is quite similar to the tables option for schemas.
tables
Create an insert method overriding the one in Alzabo::Runtime::Table. See "Loading Classes" for more details. Unless you have already defined a validate_insert method for the generated table class this method will not be overridden.
This tells MethodMaker to create get/set methods for each column a row has. These methods take a single optional argument, which if given will cause that column to be updated for the row.
Create an update method overriding the one in Alzabo::Runtime::Row. See "Loading Classes" for more details. Unless you have already defined a validate_update method for the generated row class this method will not be overridden.
Creates methods in row objects named for the table to which the relationship exists. These methods return either a single Alzabo::Runtime::Row object or a single Alzabo::Runtime::RowCursor object, depending on the cardinality of the relationship.
Alzabo::Runtime::RowCursor
Take these tables as an example.
Movie Credit --------- -------- movie_id movie_id title person_id role_name
NOTE: This option must be true if you want any of the following options to be used.
A linking table, as defined here, is a table with a two column primary key that, with each column being a foreign key to another table's primary key. These tables exist to facilitate n..n logical relationships. If both foreign_keys and linking_tables are true, then methods will be created that skip the intermediate linking tables
foreign_keys
linking_tables
Lookup columns are columns in foreign tables to which a table has a many-to-one or one-to-one relationship to the foreign table's primary key. For example, given the tables below:
Restaurant Cuisine --------- -------- restaurant_id cuisine_id name (n..1) description phone spiciness cuisine_id
If we have a Restaurant row, we might want to have methods available such as ->cuisine_description or ->cuisine_spiciness.
A self relation is when a table has a parent/child relationship with itself. Here is an example:
Location -------- location_id name parent_location_id
NOTE: If the relationship has a cardinality of 1..1 then no methods will be created, as this option is really intended for parent/child relationships. This may change in the future.
Here is an example that covers all of the possible options:
use Lingua::EN::Inflect; sub namer { my %p = @_; # Table object can be returned from the schema via methods such as $schema->User_t; return $p{table}->name . '_t' if $p{type} eq 'table'; # Column objects are returned similarly, via $schema->User_t->username_c; return $p{column}->name . '_c' if $p{type} eq 'table_column'; # If I have a row object, I can get at the columns via their names, for example $user->username; return $p{column}->name if $p{type} eq 'row_column'; # This manipulates the table names a bit to generate names. For # example, if I have a table called UserRating and a 1..n # relationship from User to UserRating, I'll end up with a method # on rows in the User table called ->Ratings which returns a row # cursor of rows from the UserRating table. if ( $p{type} eq 'foreign_key' ) { my $name = $p{foreign_key}->table_to->name; my $from = $p{foreign_key}->table_from->name; $name =~ s/$from//; if ($p{plural}) { return my_PL( $name ); } else { return $name; } } # This is very similar to how foreign keys are handled. Assume # we have the tables Restaurant, Cuisine, and RestaurantCuisine. # If we are generating a method for the link from Restaurant # through to Cuisine, we'll have a method on Restaurant table # rows called ->Cuisines, which will return a cursor of rows from # the Cuisine table. if ( $p{type} eq 'linking_table' ) { my $method = $p{foreign_key}->table_to->name; my $tname = $p{foreign_key}->table_from->name; $method =~ s/$tname//; return my_PL($method); } # Lookup columns are columns if foreign tables for which there # exists a one-to-one or many-to-one relationship. In cases such # as these, it is often the case that the foreign table is rarely # used on its own, but rather it primarily used as a lookup table # for values that should appear to be part of other tables. # # For example, an Address table might have a many-to-one # relationship with a State table. The State table would contain # the columns 'name' and 'abbreviation'. If we have # an Address table row, it is convenient to simply be able to say # $address->state_name and $address->state_abbreviation. if ( $p{type} eq 'lookup_columns' ) { return join '_', map { lc $_->name } $p{foreign_key}->table_to->name, $p{column}->name; } # This should be fairly self-explanatory. return $p{parent} ? 'parent' : 'children' if $p{type} eq 'self_relation'; # As should this. return $p{type} if grep { $p{type} eq $_ } qw( insert update ); # And just to make sure that nothing slips by us we do this. die "unknown type in call to naming sub: $p{type}\n"; } # Lingua::EN::Inflect did not handle the word 'hours' properly when this was written sub my_PL { my $name = shift; return $name if $name =~ /hours$/i; return Lingua::EN::Inflect::PL($name); }
Dave Rolsky, <autarch@urth.org>
To install Alzabo, copy and paste the appropriate command in to your terminal.
cpanm
cpanm Alzabo
CPAN shell
perl -MCPAN -e shell install Alzabo
For more information on module installation, please visit the detailed CPAN module installation guide.