fREWdiculous!
15 Aug
This week I:
9 Mar
I’m extremely proud to announce a fairly major release of DBIx::Class::Candy, 0.002000. Not only are the tests much more complete as well as the underlying code much more comprehensible, but the usage of the Candy can now be even sweeter.
To get the full features of DBIx::Class::Candy you’ll want to first create the following base class:
(Of course you can call this sugar if you hate my naming scheme or rainbows if you love it.)
1 2 3 4 5 6 7 8 9 | package MyApp::Schema::Candy; use parent 'DBIx::Class::Candy'; sub base () { 'MyApp::Schema::Result' } sub perl_version () { 12 } sub autotable () { 1 } 1; |
Now a basic id, name table would look like this:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 | package MyApp::Schema::Result::Permission; use MyApp::Schema::Candy; primary_column id => { data_type => 'int', is_auto_increment => 1, }; unique_column name => { data_type => 'varchar', size => 30, }; 1; |
id got set to the pk, name got a unique constraint, the table was named permissions, perl 5.12 features were imported, the base class was set to MyApp::Schema::Result. How awesome is that! Not that you can do the same thing as above without a subclass if you like still:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | package MyApp::Schema::Result::Permission; use DBIx::Class::Candy -base => 'MyApp::Schema::Result', -perl5 => v12, -autotable => v1; primary_column id => { data_type => 'int', is_auto_increment => 1, }; unique_column name => { data_type => 'varchar', size => 30, }; 1; |
I should give credit where credit is due. Getty had lots of ideas for improvements, but the first one I implemented (due to how easy it was and how much I liked it) was primary_column. mst had the idea of automatically generating the table name and using a subclass of candy to avoid boilerplate. Enjoy!
20 Jul
Over a year ago I read this blog post. To be honest at the time I thought it was mostly silly and I still feel that way. The things that are important to me in an ORM are capabilities, not subjective prettiness of code. But, I also get tired of typing repetitive things, especially __PACKAGE__->. That’s just too many shift keys! So after working on a few different modules and accruing various bits of knowledge here and there I learned what I needed to to create a sugar layer for DBIx::Class that doesn’t throw the baby out with the bath-water.
I am proud to announce the initial, development version of DBIx::Class::Candy, which should be coming to a CPAN mirror near you very soon. If you just can’t wait, use cpanf to get it right now. The basic gist of it is that you can use:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 | package MyApp::Schema::Result::Artist; use DBIx::Class::Candy; table 'artists'; column id => { data_type => 'int', is_auto_increment => 1, }; column name => { data_type => 'varchar', size => 25, is_nullable => 1, }; primary_key 'id'; has_many albums => 'A::Schema::Result::Album', 'artist_id'; 1; |
instead of
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 | package MyApp::Schema::Result::Artist; use strict; use warnings; use base 'DBIx::Class::Core'; __PACKAGE__->table('artists'); __PACKAGE__->add_columns( id => { data_type => 'int', is_auto_increment => 1, }, name => { data_type => 'varchar', size => 25, is_nullable => 1, } ); __PACKAGE__->set_primary_key('id'); __PACKAGE__->has_many( albums => 'A::Schema::Result::Album', 'artist_id' ); 1; |
There are a few other features, like having it turn on 5.10 or 5.12 features, use a non standard base, and more. Check it out now!