logo
Free, unlimited AI code reviews that run on commit
git-lrc git-lrc GitHub Install Now We'd appreciate a star git-lrc - Free, unlimited AI code reviews that run on commit | Product Hunt git-lrc - Free, unlimited AI code reviews that run on commit | Product Hunt

DBIx::Class::Candy::ResultSet - Sugar for your resultsets

Author

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

Description

       "DBIx::Class::Candy::ResultSet" is an initial sugar layer in the spirit of DBIx::Class::Candy.  Unlike
       the original it does not define a DSL, though I do have plans for that in the future.  For now all it
       does is set some imports:

       •   turns on strict and warnings

       •   sets your parent class

       •   sets your mro to "c3"

Import Options

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

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

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

   -components
        use DBIx::Class::Candy::ResultSet -components => ['Helper::ResultSet::Me'];

       "DBIx::Class::Candy::ResultSet" allows you to set which components you are using at import time.

   -perl5
        use DBIx::Class::Candy::ResultSet -perl5 => v20;

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

Name

       DBIx::Class::Candy::ResultSet - Sugar for your resultsets

Setting Default Import Options

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

        use DBIx::Class::Candy::ResultSet
          -base      => 'MyApp::Schema::ResultSet',
          -perl5     => v20,
          -experimental => ['signatures'];

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

        package MyApp::Schema::Candy::ResultSet;

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

        sub base { $_[1] || 'MyApp::Schema::ResultSEt' }
        sub perl_version { 20 }
        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::ResultSet
           -base => 'MyApp::Schema::ResultSet',
           -perl5 => v18,
          -experimental => ['postderef'];

       Your "base" method will get "MyApp::Schema::ResultSet", your "experimental" will get "['postderef']", and
       your "perl_version" will get 18.

Synopsis

        package MyApp::Schema::ResultSet::Artist;

        use DBIx::Class::Candy::ResultSet
          -components => ['Helper::ResultSet::Me'];

        use experimental 'signatures';

        sub by_name ($self, $name) { $self->search({ $self->me . 'name' => $name }) }

        1;

See Also