DBIx::...:Candy(3pm)

💖 DBIx::...:Candy(3pm) 💖

okay bestie, so this is a page from the User Contributed Perl Documentation set, and it's all about DBIx::Class::Candy — your fave ORM's lil sugar rush 🍓

---

✨ NAME ✨

DBIx::Class::Candy — Sugar for your favorite ORM, DBIx::Class</p> 🍬

---

🌸 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;

like, look how clean that is?? no __PACKAGE__-> spam, no nada. 💅

---

🦋 DESCRIPTION 🦋

DBIx::Class::Candy is a simple sugar layer for defining DBIx::Class results. heads up tho: it might get expanded later to add sugar for even more DBIx::Class-adjacent stuff. iykyk 👀

by default, DBIx::Class::Candy:

• turns on strict and warnings 🔇
• sets your parent class 👑
• exports a bunch of the package methods you normally use to define your DBIx::Class results
• makes a few aliases so some of the original method names are shorter or clearer ✨
• defines very few new subroutines that transform the arguments passed to them

it assumes a DBIx::Class::Core-like API, but bestie you can totally tailor it to suit your needs. 🎀

---

🎀 IMPORT OPTIONS 🎀

see "SETTING DEFAULT IMPORT OPTIONS" for how to set these schema-wide, mmkay?

-base

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

the very first thing you can do to customize your usage of DBIx::Class::Candy is change the parent class. do that with the -base import option. periodt. 💅

-autotable

use DBIx::Class::Candy -autotable => v1;

do NOT 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 lets you set which components you're using at import time, so the components can define their own sugar to export too 🍭 see DBIx::Class::Candy::Exports for the deets on how that works.

-perl5

use DBIx::Class::Candy -perl5 => v10;

ngl, i love the new features in Perl 5.10 and 5.12, so i felt like it'd be nice to remove the boilerplate of doing use feature ':5.10' and just fold it into my sugar importer. feel free not to use this, no pressure. 🌈

-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. slay. 👑

---

💜 IMPORTED SUBROUTINES 💜

most of the imported subroutines are the exact same as what you get when you use the normal interface for result definition: same names, same arguments. in general, write the code the way you normally would — just leave 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 just renamed versions of the functions you already 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 probably noticed that in the "SYNOPSIS" i used column instead of add_columns and primary_key instead of set_primary_key. the old versions still 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, bestie, i promise you:

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 like this:

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 you want honestly. 🙈

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 lets you 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 lets you 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 <frioux+cpan@gmail.com>

---

💖 COPYRIGHT AND LICENSE 💖

this software is copyright (c) 2024 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. 🫶

---

okay that's the whole thing bestie, and just so you have the receipts: this was perl v5.40.0, dated 2024-11-16, from the DBIx::...:Candy(3pm) page itself. go forth and make your schemas pretty ✨💅🎀