Provided by: libdbix-class-candy-perl_0.005003-2_all bug

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":

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

AUTHOR

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

COPYRIGHT AND LICENSE

       This software is copyright (c) 2017 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.