File: README

package info (click to toggle)
libdbix-class-candy-perl 0.002100-1
  • links: PTS, VCS
  • area: main
  • in suites: wheezy
  • size: 204 kB
  • sloc: perl: 476; makefile: 2
file content (239 lines) | stat: -rw-r--r-- 7,786 bytes parent folder | download
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
NAME
    DBIx::Class::Candy - Sugar for your favorite ORM, DBIx::Class

VERSION
    version 0.002100

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.

HERE BE DRAGONS
    Part of the goal of this module is to fix some warts of the original API
    for defining DBIx::Class results. Given that we would like to get a few
    eyeballs on it before we finalize it. If you are writing code that you
    will not touch again for years, do not use this till this warning is
    removed.

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 => 'Moose', -perl5 => v30, -autotable => v3;

    Your "base" method will get "Moose", your "perl_version" will get 30,
    and your "autotable" will get 3.

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 it's 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::Buidling -> 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) 2012 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.