Arthur Axel "fREW" Schmidt > DBIx-Class-Candy-0.002103 > DBIx::Class::Candy

Download:
DBIx-Class-Candy-0.002103.tar.gz

Dependencies

Annotate this POD

CPAN RT

Open  0
View/Report Bugs
Module Version: 0.002103   Source   Latest Release: DBIx-Class-Candy-0.002106

NAME ^

DBIx::Class::Candy - Sugar for your favorite ORM, DBIx::Class

SYNOPSIS ^

 package MyApp::Schema::Result::Artist;

 use DBIx::Class::Candy -autotable => v1;

 primary_column id => {
   data_type => 'int',
   is_auto_increment => 1,
 };

 column name => {
   data_type => 'varchar',
   size => 25,
   is_nullable => 1,
 };

 has_many albums => 'A::Schema::Result::Album', 'artist_id';

 1;

DESCRIPTION ^

DBIx::Class::Candy is a simple sugar layer for definition of DBIx::Class results. Note that it may later be expanded to add sugar for more DBIx::Class related things. By default DBIx::Class::Candy:

It assumes a DBIx::Class::Core-like API, but you can tailor it to suit your needs.

IMPORT OPTIONS ^

See "SETTING DEFAULT IMPORT OPTIONS" for information on setting these schema wide.

-base

 use DBIx::Class::Candy -base => 'MyApp::Schema::Result';

The first thing you can do to customize your usage of DBIx::Class::Candy is change the parent class. Do that by using the -base import option.

-autotable

 use DBIx::Class::Candy -autotable => v1;

Don't waste your precious keystrokes typing table 'buildings', let DBIx::Class::Candy do that for you! See "AUTOTABLE VERSIONS" for what the existing versions will generate for you.

-components

 use DBIx::Class::Candy -components => ['FilterColumn'];

DBIx::Class::Candy allows you to set which components you are using at import time so that the components can define their own sugar to export as well. See DBIx::Class::Candy::Exports for details on how that works.

-perl5

 use DBIx::Class::Candy -perl5 => v10;

I love the new features in Perl 5.10 and 5.12, so I felt that it would be nice to remove the boiler plate of doing use feature ':5.10' and add it to my sugar importer. Feel free not to use this.

IMPORTED SUBROUTINES ^

Most of the imported subroutines are the same as what you get when you use the normal interface for result definition: they have the same names and take the same arguments. In general write the code the way you normally would, leaving out the __PACKAGE__-> part. The following are methods that are exported with the same name and arguments:

 belongs_to
 has_many
 has_one
 inflate_column
 many_to_many
 might_have
 remove_column
 remove_columns
 resultset_attributes
 resultset_class
 sequence
 source_name
 table

There are some exceptions though, which brings us to:

IMPORTED ALIASES ^

These are merely renamed versions of the functions you know and love. The idea is to make your result classes a tiny bit prettier by aliasing some methods. If you know your DBIx::Class API you noticed that in the "SYNOPSIS" I used column instead of add_columns and primary_key instead of set_primary_key. The old versions work, this is just nicer. A list of aliases are as follows:

 column            => 'add_columns',
 primary_key       => 'set_primary_key',
 unique_constraint => 'add_unique_constraint',
 relationship      => 'add_relationship',

SETTING DEFAULT IMPORT OPTIONS ^

Eventually you will get tired of writing the following in every single one of your results:

 use DBIx::Class::Candy
   -base      => 'MyApp::Schema::Result',
   -perl5     => v12,
   -autotable => v1;

You can set all of these for your whole schema if you define your own Candy subclass as follows:

 package MyApp::Schema::Candy;

 use base 'DBIx::Class::Candy';

 sub base { $_[1] || 'MyApp::Schema::Result' }
 sub perl_version { 12 }
 sub autotable { 1 }

Note the $_[1] || in base. All of these methods are passed the values passed in from the arguments to the subclass, so you can either throw them away, honor them, die on usage, or whatever. To be clear, if you define your subclass, and someone uses it as follows:

 use MyApp::Schema::Candy -base => 'Moose', -perl5 => v30, -autotable => v3;

Your base method will get Moose, your perl_version will get 30, and your autotable will get 3.

SECONDARY API ^

has_column

There is currently a single "transformer" for add_columns, so that people used to the Moose api will feel more at home. Note that this may go into a "Candy Component" at some point.

Example usage:

 has_column foo => (
   data_type => 'varchar',
   size => 25,
   is_nullable => 1,
 );

primary_column

Another handy little feature that allows you to define a column and set it as the primary key in a single call:

 primary_column id => {
   data_type => 'int',
   is_auto_increment => 1,
 };

If your table has multiple columns in it's primary key, merely call this method for each column:

 primary_column person_id => { data_type => 'int' };
 primary_column friend_id => { data_type => 'int' };

unique_column

This allows you to define a column and set it as unique in a single call:

 unique_column name => {
   data_type => 'varchar',
   size => 30,
 };

AUTOTABLE VERSIONS ^

Currently there is a single version, v1, which looks at your class name, grabs everything after ::Schema::Result:: (or ::Result::), removes the ::'s, converts it to underscores instead of camel-case, and pluralizes it. Here are some examples if that's not clear:

 MyApp::Schema::Result::Cat -> cats
 MyApp::Schema::Result::Software::Buidling -> software_buildings
 MyApp::Schema::Result::LonelyPerson -> lonely_people
 MyApp::DB::Result::FriendlyPerson -> friendly_people
 MyApp::DB::Result::Dog -> dogs

Also, if you just want to be different, you can easily set up your own naming scheme. Just add a gen_table method to your candy subclass. The method gets passed the class name and the autotable version, which of course you may ignore. For example, one might just do the following:

 sub gen_table {
   my ($self, $class) = @_;

   $class =~ s/::/_/g;
   lc $class;
 }

Which would tranform MyApp::Schema::Result::Foo into myapp_schema_result_foo.

Or maybe instead of using the standard MyApp::Schema::Result namespace you decided to be different and do MyApp::DB::Table or something silly like that. You could pre-process your class name so that the default gen_table will still work:

 sub gen_table {
   my $self = shift;
   my $class = $_[0];

   $class =~ s/::DB::Table::/::Schema::Result::/;
   return $self->next::method(@_);
 }

AUTHOR ^

Arthur Axel "fREW" Schmidt <frioux+cpan@gmail.com>

COPYRIGHT AND LICENSE ^

This software is copyright (c) 2012 by Arthur Axel "fREW" Schmidt.

This is free software; you can redistribute it and/or modify it under the same terms as the Perl 5 programming language system itself.

syntax highlighting: