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

-experimental

 use DBIx::Class::Candy -experimental => ['signatures'];

I would like to use signatures and postfix dereferencing in all of my "DBIx::Class" classes. This makes that goal trivial.

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 its 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,
 };

"v1"

It 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::Building -> software_buildings
 MyApp::Schema::Result::LonelyPerson -> lonely_people
 MyApp::DB::Result::FriendlyPerson -> friendly_people
 MyApp::DB::Result::Dog -> dogs

'singular'

It looks at your class name, grabs everything after "::Schema::Result::" (or "::Result::"), removes the "::"'s and converts it to underscores instead of camel-case. Here are some examples if that's not clear:

 MyApp::Schema::Result::Cat -> cat
 MyApp::Schema::Result::Software::Building -> software_building
 MyApp::Schema::Result::LonelyPerson -> lonely_person
 MyApp::DB::Result::FriendlyPerson -> friendly_person
 MyApp::DB::Result::Dog -> dog

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 transform "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(@_);
 }