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:

      * turns on strict and warnings

      * sets your parent class

      * exports a bunch of the package methods that you normally use to
      define your DBIx::Class results

      * makes a few aliases to make some of the original method names a
      shorter or more clear

      * defines very few new subroutines that transform the arguments
      passed to them

    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.

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

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,
       -experimental => ['signatures'];

    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 }
     sub experimental { ['signatures'] }

    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 => 'MyApp::Schema::Result',
        -perl5 => v18,
        -autotable => v1,
        -experimental => ['postderef'];

    Your base method will get MyApp::Schema::Result, your perl_version will
    get 18, your experimental will get ['postderef'], and your autotable
    will get 1.

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

AUTOTABLE VERSIONS

    Currently there are two versions:

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