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 <[email protected]>

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.

You are viewing proxied material from ftp.icm.edu.pl. The copyright of proxied material belongs to its original authors. Any comments or complaints in relation to proxied material should be directed to the original authors of the content concerned. Please see the disclaimer for more details.