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 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.
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;
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 }
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;
Your "base" method will get "MyApp::Schema::Result", your
"perl_version" will get 18, 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 is a single version, "v1", which 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
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(@_);
}
AUTHOR¶
Arthur Axel "fREW" Schmidt <frioux+cpan@gmail.com>
COPYRIGHT AND LICENSE¶
This software is copyright (c) 2014 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.