Provided by: librose-db-object-perl_0.820-2_all 
NAME
Rose::DB::Object::Tutorial - A guided tour of the basics of Rose::DB::Object
INTRODUCTION
This document provides a step-by-step introduction to the Rose::DB::Object module
distribution. It demonstrates all of the important features using a semi-realistic
example database. This tutorial does not replace the actual documentation for each
module, however. The "reference" documentation found in each ".pm" file is still
essential, and contains some good examples of its own.
This tutorial provides a gradual introduction to Rose::DB::Object. It also describes
"best practices" for using Rose::DB::Object in the most robust, maintainable manner. If
you're just trying to get a feel for what's possible, you can skip to the end and take a
look at the completed example database and associated Perl code. But I recommend reading
the tutorial from start to finish at least once.
The examples will start simple and get progressively more complex. You, the developer,
have to decide which level of complexity or abstraction is appropriate for your particular
task.
CONVENTIONS
Some of the examples in this tutorial will use the fictional "My::" namespace prefix.
Some will use no prefix at all. Your code should use whatever namespace you deem
appropriate. Usually, it will be something like "MyCorp::MyProject::" (i.e., your
corporation, organization, and/or project). I've chosen to use "My::" or to omit the
prefix entirely simply because this produces shorter class names, which will help this
tutorial stay within an 80-column width.
For the sake of brevity, the "use strict" directive and associated "my" declarations have
also been omitted from the example code. Needless to say, you should always "use strict"
in your actual code.
Similarly, the traditional "1;" true value used at the end of each ".pm" file has been
omitted from the examples. Don't forget to add this to the end of your actual Perl module
files.
Although most of the examples in this tutorial use the base.pm module to set up
inheritance, directly modifying the @ISA package variable usually works just as well. In
situations where there are circular relationships between classes, the "use base ..." form
may be preferable because it runs at compile-time, whereas @ISA modification happens at
run-time. In either case, it's a good idea to set up inheritance as early as possible in
each module.
package Product;
# Set up inheritance first
use base qw(Rose::DB::Object);
# Then do other stuff...
...
TUTORIAL
Preface
Before doing anything useful with Rose::DB::Object, it's necessary to create and configure
a Rose::DB subclass through which Rose::DB::Object-derived objects will access the
database.
To get up to speed quickly with Rose::DB, read the Rose::DB::Tutorial documentation. The
rest of this tutorial will assume the existence of a "My::DB" class created as described
in the Rose::DB tutorial. Here's a possible incarnation of the "My::DB" class.
package My::DB;
use base qw(Rose::DB);
__PACKAGE__->use_private_registry;
__PACKAGE__->register_db(
driver => 'pg',
database => 'mydb',
host => 'localhost',
username => 'devuser',
password => 'mysecret',
);
Read the Rose::DB tutorial for an explanation of this code.
The PostgreSQL database will be used in the examples in this tutorial, but the features
demonstrated will not be specific to that database. If you are following along with a
different database, you may have to adjust the specific syntax used in the SQL table
creation statements, but all of the same features should be present in some form.
This tutorial is based on a fictional database schema for a store-like application. Both
the database schema the corresponding Perl classes will evolve over the course of this
document.
Getting started
Let's start with a single table in our fictional store database.
CREATE TABLE products
(
id SERIAL NOT NULL PRIMARY KEY,
name VARCHAR(255) NOT NULL,
price DECIMAL(10,2) NOT NULL DEFAULT 0.00,
UNIQUE(name)
);
Here's a basic Rose::DB::Object class to front that table:
package Product;
use base qw(Rose::DB::Object);
__PACKAGE__->meta->setup
(
table => 'products',
columns => [ qw(id name price) ],
pk_columns => 'id',
unique_key => 'name',
);
The steps are simple:
1. Inherit from Rose::DB::Object.
2. Name the table.
3. Name the columns.
4. Name the primary key column(s).
5. Add unique keys (if any).
6. Initialize. (Implied at the end of the setup call)
Operations 2 through 6 are done through the setup method on the metadata object associated
with this class. The table must have a primary key, and may have zero or more unique
keys. The primary key and each unique key may contain multiple columns.
Of course, earlier it was established that Rose::DB needs to be set up for any
Rose::DB::Object class to work properly. To that end, this tutorial assumes the existence
of a Rose::DB subclass named My::DB that is set up according to the best practices of
Rose::DB. We need to make the "Product" class use My::DB. Here's one way to do it:
package Product;
use My::DB;
use base qw(Rose::DB::Object);
__PACKAGE__->meta->setup
(
table => 'products',
columns => [ qw(id name price) ],
pk_columns => 'id',
unique_key => 'name',
);
sub init_db { My::DB->new }
Now "Product" will create a My::DB object when it needs to connect to the database.
Note that the "My::DB->new" call in "init_db()" means that each "Product" object will have
its own, private "My::DB" object. See the section below, "A brief digression: database
objects", for an explanation of this setup and some alternatives.
Setting up your own base class
Looking forward, it's likely that all of our Rose::DB::Object-derived classes will want to
use My::DB objects when connecting to the database. It's tedious to repeat this code in
all of those classes. A common base class can provide a single, shared location for that
code.
package My::DB::Object;
use My::DB;
use base qw(Rose::DB::Object);
sub init_db { My::DB->new }
(Again, note that all "My::DB::Object"-derived objects will get their own "My::DB" objects
given this definition of "init_db()". See the "digression" section below for more
information.)
Now the "Product" class can inherit from "My::DB::Object" instead of inheriting from
Rose::DB::Object directly.
package Product;
use base 'My::DB::Object';
__PACKAGE__->meta->setup
(
table => 'products',
columns => [ qw(id name price) ],
pk_columns => 'id',
unique_key => 'name',
);
This use of a common base class is strongly recommended. You will see this pattern
repeated in the Rose::DB tutorial as well. The creation of seemingly "trivial" subclasses
is a cheap and easy way to ensure ease of extensibility later on.
For example, imagine we want to add a "copy()" method to all of our database objects. If
they all inherit directly from "Rose::DB::Object", that's not easy to do. But if they all
inherit from "My::DB::Object", we can just add the "copy()" method to that class.
The lesson is simple: when in doubt, subclass. A few minutes spent now can save you a lot
more time down the road.
Rose::DB::Object in action
Now that we have our "Product" class all set up, let's see what we can do with it.
Get and set column values
By default, each column has a combined accessor/mutator method. When passed a value, the
column value is set and returned. When called with no arguments, the value is simply
returned.
$p->name('Bike'); # set name
print $p->name; # get name
Since Rose::DB::Object inherits from Rose::Object, each object method is also a valid
constructor argument.
$p = Product->new(name => 'Cane', price => 1.99);
print $p->price; # 1.99
Load
An object can be loaded based on a primary key.
$p = Product->new(id => 1); # primary key
$p->load; # Load the object from the database
An object can also be loaded based on a unique key:
$p = Product->new(name => 'Sled'); # unique key
$p->load; # Load the object from the database
If there is no row in the database table with the specified primary or unique key value,
the call to load() will fail. Under the default error mode, an exception will be thrown.
To safely check whether or not such a row exists, use the "speculative" parameter.
$p = Product->new(id => 1);
unless($p->load(speculative => 1))
{
print "No such product with id = 1";
}
Regardless of the error mode, load() will simply return true or false when the
"speculative" parameter is used.
Insert
To insert a row, create an object and then save it.
$p = Product->new(id => 123, name => 'Widget', price => 4.56);
$p->save; # Insert the object into the database
The default error mode will throw an exception if anything goes wrong during the save, so
we don't have to check the return value.
Here's another variation:
$p = Product->new(name => 'Widget', price => 1.23);
$p->save;
print $p->id; # print the auto-generated primary key value
Since the primary key of the "products" table, "id", is a SERIAL column, a new primary key
value will be automatically generated if one is not specified. After the object is saved,
we can retrieve the auto-generated value.
Update
To update a row, simply save an object that has been previously loaded or saved.
$p1 = Product->new(name => 'Sprocket', price => 9.99);
$p1->save; # Insert a new object into the database
$p1->price(12.00);
$p1->save; # Update the object in the database
$p2 = Product->new(id => 1);
$p2->load; # Load an existing object
$p2->name($p2->name . ' Mark II');
$p2->save; # Update the object in the database
Delete
An object can be deleted based on a primary key or a unique key.
$p = Product->new(id => 1); # primary key
$p->delete; # Delete the object from the database
$p = Product->new(name => 'Sled'); # unique key
$p->delete; # Delete the object from the database
The delete method will return true if the row was deleted or did not exist, false
otherwise.
It works just as well with objects that have been loaded or saved.
$p1 = Product->new(name => 'Sprocket', price => 9.99);
$p1->save; # Insert a new object into the database
$p1->delete; # Now delete the object
$p2 = Product->new(id => 1);
$p2->load; # Load an existing object
$p2->delete; # Now delete the object
Multiple objects
The examples above show SELECT, INSERT, UPDATE, and DELETE operations on one row at time
based on primary or unique keys. What about manipulating rows based on other criteria?
What about manipulating multiple rows simultaneously? Enter Rose::DB::Object::Manager, or
just "the manager" for short.
But why is there a separate class for dealing with multiple objects? Why not simply add
more methods to the object itself? Say, a "search()" method to go alongside load(),
save(), delete() and friends? There are several reasons.
First, it's somewhat "semantically impure" for the class that represents a single row to
also be the class that's used to fetch multiple rows. It's also important to keep the
object method namespace as sparsely populated as possible. Each new object method
prevents a column with the same name from using that method name. Rose::DB::Object tries
to keep the list of reserved method names as small as possible.
Second, inevitably, classes grow. It's important for the object manager class to be
separate from the object class itself so each class can grow happily in isolation, with no
potential for namespace or functionality clashes.
All of that being said, Rose::DB::Object::Manager does include support for adding manager
methods to the object class. Obviously, this practice is not recommended, but it exists
if you really want it.
Anyway, let's see some examples. Making a manager class is simply a matter of inheriting
from Rose::DB::Object::Manager, specifying the object class, and then creating a series of
appropriately named wrapper methods.
package Product::Manager;
use base qw(Rose::DB::Object::Manager);
sub object_class { 'Product' }
__PACKAGE__->make_manager_methods('products');
The call to make_manager_methods() creates the following methods:
get_products
get_products_iterator
get_products_count
delete_products
update_products
The names are pretty much self-explanatory. You can read the Rose::DB::Object::Manager
documentation for all the gory details. The important thing to note is that the methods
were all named based on the "products" argument to make_manager_methods(). You can see
how "products" has been incorporated into each of the method names.
This naming scheme is just a suggestion. You can name these methods anything you want
(using the "methods" parameter to the make_manager_methods() call), or you can even write
the methods yourself. Each of these methods is a merely a thin wrapper around the
generically-named methods in Rose::DB::Object::Manager. The wrappers pass the specified
object class to the generic methods.
The Perl code for the "Product::Manager" class shown above can be generated automatically
by calling the perl_manager_class method on the Rose::DB::Object::Metadata that's
associated with the "Product" class. Similarly, the make_manager_class method called on
the "Product" metadata object will both generate the code and evaluate it for you,
automating the entire process of creating a manager class from within your
Rose::DB::Object-derived class.
package Product;
use base qw(Rose::DB::Object);
...
# This actually creates the Product::Manager class
# as shown in the code sample above.
__PACKAGE__->meta->make_manager_class('products');
As the comment says, the call to make_manager_class will create a standalone
"Product::Manager" class in memory. See the documentation for the perl_manager_class and
make_manager_class methods for more information.
If you decide not to heed my advice, but instead decide to create these methods inside
your Rose::DB::Object-derived class directly, you can do so by calling
make_manager_methods() from within your object class.
package Product;
use Rose::DB::Object::Manager;
use base 'My::DB::Object';
...
Rose::DB::Object::Manager->make_manager_methods('products');
This will be the last you see of this technique in this tutorial. All of the examples
will assume that the recommended approach is used instead.
Fetching objects
The most common task for the manager is fetching multiple objects. We'll use the
"get_products()" method to do that. It's based on the get_objects() method, which takes
many parameters.
One (optional) parameter is the now-familiar db object used to connect to the database.
This parameter is valid for all Rose::DB::Object::Manager methods. In the absence of this
parameter, the init_db() method of the object class will be called in order to create one.
Passing no arguments at all will simply fetch every "Product" object in the database.
$products = Product::Manager->get_products();
foreach my $product (@$products)
{
print $product->name, "\n";
}
The return value is a reference to an array of "Product" objects. Now let's go to the
other extreme.
$products =
Product::Manager->get_products(
query =>
[
name => { like => '%Hat' },
id => { ge => 7 },
or =>
[
price => 15.00,
price => { lt => 10.00 },
],
],
sort_by => 'name',
limit => 10,
offset => 50);
That call produces SQL that looks something like this:
SELECT id, name, price FROM products WHERE
name LIKE '%Hat' AND
id >= 7 AND
(price = 15.00 OR price < 10.00)
ORDER BY name
LIMIT 10 OFFSET 50
Manager queries support nested boolean logic and several different kinds of comparison
operators. For a full explanation of all the options, see the Rose::DB::Object::Manager
documentation.
The iterator method takes the same kinds of arguments, but returns an iterator that will
fetch the objects from the database one at a time.
$iterator = Product::Manager->get_products_iterator(...);
while($product = $iterator->next)
{
print $product->id, ' ', $product->name, "\n";
$iterator->finish if(...); # exit early?
}
print $iterator->total; # total iterated over
Note that this is a "real" iterator. Objects not iterated over are not fetched from the
database at all.
Counting objects
Counting objects is straightforward. The "get_products_count()" method takes the same
kinds of arguments as "get_products()" and "get_products_iterator()". It returns the
count.
$num_cheap_products =
Product::Manager->get_products_count(
query => [ price => { lt => 1.00 } ]);
Deleting objects
The "delete_products()" method accepts the same kinds of "query" arguments as the manager
methods described above, only it uses the parameter name "where" instead.
$num_rows_deleted =
Product::Manager->delete_products(
where =>
[
id => { ne => 123 },
name => { like => 'Wax%' },
]);
Updating objects
The "update_products()" method accepts the same kinds of arguments as the
"delete_products()" method, plus a "set" parameter to specify the actual update
information.
$num_rows_updated =
Product::Manager->update_products(
set =>
{
price => 5.00,
},
where =>
[
price => 4.99,
id => { gt => 100 },
]);
The end of the beginning
This section has covered the bare minimum usage and functionality of the Rose::DB::Object
module distribution. Using these features alone, you can automate the basic CRUD
operations (Create, Retrieve, Update, and Delete) for single or multiple objects. But
it's almost a shame to stop at this point. There's a lot more that Rose::DB::Object can
do for you. The "sweet spot" of effort vs. results is much farther along the curve.
In the next section, we will expand upon our "Product" class and tap more of
Rose::DB::Object's features. But first...
A brief digression: database objects
The Rose::DB-derived database object used by each Rose::DB::Object-derived object is
available via the db object attribute.
$p = Product->new(...);
$db = $p->db; # My::DB object
You can read the Rose::DB documentation to explore the capabilities of these db objects.
Most of the time, you won't have to be concerned about them. But it's sometime useful to
deal with them directly.
The first thing to understand is where the database object comes from. If the db
attribute doesn't exist, it is created by calling init_db(). The typical "init_db()"
method simply builds a new database object and returns it. (See the Rose::DB tutorial for
an explanation of the possible arguments to new(), and why there are none in the call
below.)
package Product;
...
sub init_db { My::DB->new }
This means that each "Product" object will have its own "My::DB" object, and therefore (in
the absence of modules like Apache::DBI) its own connection to the database.
If this not what you want, you can make "init_db()" return the same "My::DB" object to
every "Product" object. This will make it harder to ensure that the database handle will
be closed when all "Product" objects go out of scope, but that may not be important for
your application. The easiest way to do this is to call new_or_cached instead of new.
package Product;
...
sub init_db { My::DB->new_or_cached }
Since "init_db()" is only called if a "Product" object does not already have a db object,
another way to share a single "My::DB" object with several "Product" objects is to do so
explicitly, either by pre-creating the "My::DB" object:
$db = My::DB->new; # will share this db with the Products below
$p1 = Product->new(db => $db, ...);
$p2 = Product->new(db => $db, ...);
$p3 = Product->new(db => $db, ...);
or by letting one of the "Product" objects provide the db for the rest.
$p1 = Product->new(...);
$p2 = Product->new(db => $p1->db, ...); # use $p1's db
$p3 = Product->new(db => $p1->db, ...); # use $p1's db
A note for mod_perl users: when using Apache::DBI, even if each "Product" has its own
"My::DB" object, remember that they will all share a single underlying DBI database
handle. That is, each Rose::DB-derived object of a given type and domain will eventually
call DBI's connect() method with the same arguments, and therefore return the same, cached
database handle when running under Apache::DBI. The default cache implementation
underlying the new_or_cached method is also mod_perl-aware and will cooperate with
Apache::DBI.
Here's an example where sharing a database object is important: creating several "Product"
objects in a single transaction.
$db = My::DB->new;
$db->begin_work; # Start transaction
# Use this $db with each product object
$p1 = Product->new(name => 'Bike', db => $db);
$p1->save;
$p2 = Product->new(name => 'Sled', db => $db);
$p2->save;
$p3 = Product->new(name => 'Kite', db => $db);
$p3->save;
if(...) # Now either commit them all or roll them all back
{
$db->commit;
}
else
{
$db->rollback;
}
Cross-database migration is another important use for explicitly shared db objects.
Here's how to move a product from a production database to an archive database.
$production_db = My::DB->new('production');
$archive_db = My::DB->new('archive');
# Load bike from production database
$p = Product->new(name => 'Bike', db => $production_db);
$p->load;
# Save the bike into the archive database
$p->db($archive_db);
$p->save(insert => 1); # force an insert instead of an update
# Delete the bike from the production database
$p->db($production_db);
$p->delete;
Mainstream usage
Let's imagine that the "products" table has expanded. It now looks like this.
CREATE TABLE products
(
id SERIAL NOT NULL PRIMARY KEY,
name VARCHAR(255) NOT NULL,
price DECIMAL(10,2) NOT NULL DEFAULT 0.00,
status VARCHAR(128) NOT NULL DEFAULT 'inactive'
CHECK(status IN ('inactive', 'active', 'defunct')),
date_created TIMESTAMP NOT NULL DEFAULT NOW(),
release_date TIMESTAMP,
UNIQUE(name)
);
We could do a straightforward expansion of the "Product" class as designed in the previous
section.
package Product;
use base 'My::DB::Object';
__PACKAGE__->meta->setup
(
table => 'products',
columns => [ qw(id name price status date_created release_date) ],
pk_columns => 'id',
unique_key => 'name',
);
But now we're faced with a few problems. First, while the "status" column only accepts a
few pre-defined values, our "Product" object will gladly accept any status value. But
maybe that's okay because the database will reject invalid values, causing an exception
will be thrown when the object is saved.
The date/time fields are more troubling. What is the format of a valid value for a
TIMESTAMP column in PostgreSQL? Consulting the PostgreSQL documentation will yield the
answer, I suppose. But now all the code that uses "Product" objects has to be sure to
format the "date_created" and "release_date" values accordingly. That's even more
difficult if some of those values come from external sources, such as a web form.
Worse, what if we decide to change databases in the future? We'd have to hunt down every
single place where a "date_created" or "release_date" value is set and then modify the
formatting to match whatever format the new database wants. Oh, and we'll have to look
that up too. Blah.
Finally, what about all those default values? The "price" column already had a default
value, but now two more columns also have defaults. True, the database will take care of
this when a row is inserted, but now the Perl object is diverging more and more from the
database representation.
Let's solve all of these problems. If we more accurately describe the columns,
Rose::DB::Object will do the rest.
package Product;
use base 'My::DB::Object';
__PACKAGE__->meta->setup
(
table => 'products',
columns =>
[
id => { type => 'serial', primary_key => 1, not_null => 1 },
name => { type => 'varchar', length => 255, not_null => 1 },
price =>
{
type => 'decimal',
precision => 10,
scale => 2,
not_null => 1,
default => 0.00
},
status =>
{
type => 'varchar',
length => 128,
not_null => 1,
default => 'inactive',
check_in => [ 'inactive', 'active', 'defunct' ],
},
date_created => { type => 'timestamp', not_null => 1,
default => 'now()' },
release_date => { type => 'timestamp' },
],
unique_key => 'name',
allow_inline_column_values => 1,
);
Before examining what new functionality this new class gives us, there are a few things to
note about the definition. First, the primary key is no longer specified with the
primary_key_columns() method. Instead, the "id" column has its "primary_key" attribute
set to a true value in its description.
Second, note the default value for the "date_created" column. It's a string containing a
call to the PL/SQL function "now()", which can actually only be run within the database.
But thanks to the allow_inline_column_values attribute being set to a true value,
Rose::DB::Object will pass the string "now()" through to the database as-is.
In the case of "creation date" columns like this, it's often better to let the database
provide the value as close as possible to the very moment the row is created. On the
other hand, this will mean that any newly created "Product" object will have a "strange"
value for that column (the string "now()") until/unless it is re-loaded from the database.
It's a trade-off.
Let's see the new "Product" class in action. The defaults work as expected.
$p = Product->new;
print $p->status; # 'inactive'
print $p->price; # 0.00
The "status" method now restricts its input, throwing an exception if the input is
invalid.
$p->status('nonesuch'); # Boom! Invalid status: 'nonesuch'
The timestamp columns now accept any value that Rose::DateTime::Util's parse_date() method
can understand.
$p->release_date('2005-01-22 18:00:57');
$p->release_date('12/24/1980 10am');
See the Rose::DateTime::Util documentation for a full list of acceptable formats.
Inside a "Product" object, date/time information is stored in DateTime objects.
$dt = $p->release_date; # DateTime object
Since DateTime objects can be modified in-place, doing a formerly thorny task like date
math is now trivial.
$p->release_date->add(days => 1);
The "release_date()" method also accepts a DateTime object as an input, of course:
$p->release_date(DateTime->new(...));
There are even a few convenience functions triggered by passing a name/value pair.
# Thursday, December 25th 1980 at 10:00:00 AM
print $p->release_date(format => '%A, %B %E %Y at %t');
# Clone the DateTime object, truncate the clone, and return it
$month_start = $p->release_date(truncate => 'month');
print $month_start->strftime('%Y-%m-%d'); # 1980-12-01
Conveniently, Rose::DB::Object::Manager queries can also use any values that the
corresponding column methods will accept. For example, here's a query that filters on the
"release_date" column using a DateTime object.
$last_week = DateTime->now->subtract(weeks => 1);
$products =
Product::Manager->get_products(
query =>
[
release_date => { lt => $last_week },
],
sort_by => 'release_date');
The upshot is that you no longer have to be concerned about the details of the date/time
format(s) understood by the underlying database. You're also free to use DateTime objects
as a convenient interchange format in your code.
This ability isn't just limited to date/time columns. Any data type that requires special
formatting in the database, and/or is more conveniently dealt with as a more "rich" value
on the Perl side of the fence is fair game for this treatment.
Some other examples include the bitfield column type, which is represented by a
Bit::Vector object on the Perl side, and the boolean column type which evaluates the
"truth" of its arguments and coerces the value accordingly. In all cases, column values
are automatically formatted as required by the native column data types in the database.
In some circumstances, Rose::DB::Object can even "fake" a data type for use with a
database that does not natively support it. For example, the array column type is
natively supported by PostgreSQL, but it will also work with MySQL using a VARCHAR column
as a stand-in.
Finally, if you're concerned about the performance implications of "inflating" column
values from strings and numbers into (relatively) large objects, rest assured that such
inflation is only done as needed. For example, an object with ten date/time columns can
be loaded, modified, and saved without ever creating a single DateTime object, provided
that none of the date/time columns were among those whose values were modified.
Put another way, the methods that service the columns have an awareness of the producer
and consumer of their data. When data is coming from the database, the column methods
accept it as-is. When data is being sent to the database, it is formatted appropriately,
if necessary. If a column value was not modified since it was loaded from the database,
then the value that was loaded is simply returned as-is. In this way, data can make a
round-trip without ever being inflated, deflated, or formatted.
This behavior is not a requirement of all column methods, but it is a recommended
practice--one followed by all the column classes that are part of the Rose::DB::Object
distribution.
Auto-initialization and the convention manager
The "Product" class set up in the previous section is useful, but it also takes
significantly more typing to set up. Over the long term, it's still a clear win. On the
other hand, a lot of the details in the column descriptions are already known by the
database: column types, default values, maximum lengths, etc. It would be handy if we
could ask the database for this information instead of looking it up and typing it in
manually.
This process of interrogating the database in order to extract metadata is called "auto-
initialization." There's an entire section of the Rose::DB::Object::Metadata
documentation dedicated to the topic. The executive summary is that auto-initialization
saves work in the short-run, but with some long-term costs. Read the friendly manual for
the details. For the purposes of this tutorial, I will simply demonstrate the features,
culminating in the suggested best practice.
Let's start by applying auto-initialization to the "Product" class.
package Product;
use base 'My::DB::Object';
__PACKAGE__->meta->table('products');
__PACKAGE__->meta->auto_initialize;
Believe it or not, that class is equivalent to the previous incarnation, right down to the
details of the columns and the unique key. As long as the table is specified,
Rose::DB::Object will dig all the rest of the information out of the database. Handy!
In fact, that class can be shortened even further with the help of the convention manager.
package Product;
use base 'My::DB::Object';
__PACKAGE__->meta->auto_initialize;
Now even the table is left unspecified. How does Rose::DB::Object know what to do in this
case? Why, by convention, of course. The default convention manager dictates that class
names are singular and TitleCased, and their corresponding table names are lowercase and
plural. Thus, the omitted table name in the "Product" class is, by convention, assumed to
be named "products".
Like auto-initialization, the convention manager is handy, but may also present some
maintenance issues. I tend to favor a more explicitly approach, but I can also imagine
scenarios where the convention manager is a good fit.
Keep in mind that customized convention managers are possible, allowing individual
organizations or projects to define their own conventions. You can read all about it in
the Rose::DB::Object::ConventionManager documentation.
Anyway, back to auto-initialization. Yes, auto_initialize() will dig out all sorts of
interesting and important information for you. Unfortunately, it will dig that
information out every single time the class is loaded. Worse, this class will fail to
load at all if a database connection is not immediately available.
Auto-initialization seems like something that is best done only once, with the results
being saved in a more conventional form. That's just what Rose::DB::Object::Metadata's
code generation functions are designed to do. The "perl_*" family of methods can generate
snippets of Perl code, or even entire classes, based on the results of the auto-
initialization process. They'll even honor some basic code formatting directives.
package Product;
use base 'My::DB::Object';
__PACKAGE__->meta->table('products');
__PACKAGE__->meta->auto_initialize;
print __PACKAGE__->meta->perl_class_definition(indent => 2,
braces => 'bsd');
Here's the output of that print statement. A few long lines were manually wrapped, but
it's otherwise unmodified.
package Product;
use strict;
use base 'My::DB::Object';
__PACKAGE__->meta->setup
(
table => 'products',
columns =>
[
id => { type => 'integer', not_null => 1 },
name => { type => 'varchar', length => 255, not_null => 1 },
price => { type => 'numeric', default => '0.00',
not_null => 1, precision => 10, scale => 2 },
vendor_id => { type => 'integer' },
status => { type => 'varchar', default => 'inactive',
length => 128, not_null => 1 },
date_created => { type => 'timestamp', default => 'now()',
not_null => 1 },
release_date => { type => 'timestamp' },
],
primary_key_columns => [ 'id' ],
unique_keys => [ 'name' ],
allow_inline_column_values => 1,
);
1;
Copy and paste that output back into the "Product.pm" file and you're in business.
The door is open to further automation through scripts that call the methods demonstrated
above. Although it's my inclination to work towards a static, explicit type of class
definition, the tools are there for those who prefer a more dynamic approach.
Foreign keys
When a column in one table references a row in another table, the referring table is said
to have a "foreign key." As with primary and unique keys, Rose::DB::Object supports
foreign keys made up of more than one column.
In the context of Rose::DB::Object, a foreign key is a database-supported construct that
ensures that any non-null value in a foreign key column actually refers to an existing row
in the foreign table. Databases that enforce this constraint are said to support
"referential integrity." Foreign keys are only applicable to Rose::DB::Object-derived
classes when the underlying database supports "native" foreign keys and enforces
referential integrity.
While it's possible to define foreign keys in a Rose::DB::Object-derived class even if
there is no support for them in the database, this is considered bad practice. If you're
just trying to express some sort of relationship between two tables, there's a more
appropriate way to do so. (More on that in the next section.)
Let's add a foreign key to the "products" table. First, we'll need to create the table
that the foreign key will reference.
CREATE TABLE vendors
(
id SERIAL NOT NULL PRIMARY KEY,
name VARCHAR(255) NOT NULL,
UNIQUE(name)
);
When dealing with any kind of inter-table relationship, Rose::DB::Object requires a
Rose::DB::Object-derived class fronting each participating table. So we need a class for
the "vendors" table.
package Vendor;
use base 'My::DB::Object';
__PACKAGE__->meta->setup
(
table => 'vendors',
columns =>
[
id => { type => 'serial', primary_key => 1, not_null => 1 },
name => { type => 'varchar', length => 255, not_null => 1 },
],
unique_key => 'name',
);
Now we'll add the foreign key to our ever-growing "products" table.
CREATE TABLE products
(
id SERIAL NOT NULL PRIMARY KEY,
name VARCHAR(255) NOT NULL,
price DECIMAL(10,2) NOT NULL DEFAULT 0.00,
vendor_id INT REFERENCES vendors (id),
status VARCHAR(128) NOT NULL DEFAULT 'inactive'
CHECK(status IN ('inactive', 'active', 'defunct')),
date_created TIMESTAMP NOT NULL DEFAULT NOW(),
release_date TIMESTAMP,
UNIQUE(name)
);
Finally, here's how the foreign key definition looks in the Perl class.
package Product;
use base 'My::DB::Object';
__PACKAGE__->meta->setup
(
table => 'products',
columns =>
[
id => { type => 'integer', not_null => 1 },
name => { type => 'varchar', length => 255, not_null => 1 },
price => { type => 'numeric', default => '0.00',
not_null => 1, precision => 10, scale => 2 },
vendor_id => { type => 'integer' },
status => { type => 'varchar', default => 'inactive',
length => 128, not_null => 1 },
date_created => { type => 'timestamp', default => 'now()',
not_null => 1 },
release_date => { type => 'timestamp' },
],
primary_key_columns => [ 'id' ],
unique_keys => [ 'name' ],
allow_inline_column_values => 1,
foreign_keys =>
[
vendor =>
{
class => 'Vendor',
key_columns => { vendor_id => 'id' },
},
],
);
Note that a "vendor_id" column is added to the column list. This needs to be done
independently of any foreign key definition. It's a new column, so it needs to be in the
column list. There's nothing more to it than that.
There's also the foreign key definition itself. The name/hashref-value pair passed to the
foreign_keys() method is (roughly) shorthand for this.
Rose::DB::Object::Metadata::ForeignKey->new(
name => 'vendor',
class => 'Vendor',
key_columns => { vendor_id => 'id' });
In other words, "vendor" is the name of the foreign key, and the rest of the information
is used to set attributes on the foreign key object. You could, in fact, construct your
own foreign key objects and pass them to foreign_keys() (or add_foreign_keys(), etc.)
but that would require even more typing.
Going in the other direction, since our class and column names match up with what the
convention manager expects, we could actually shorten the foreign key setup code to this.
foreign_keys => [ 'vendor' ],
Given only a foreign key name, the convention manager will derive the "Vendor" class name
and will find the "vendor_id" column in the "Product" class and match it up to the primary
key of the "vendors" table. As with most things in Rose::DB::Object class setup, you can
be as explicit or as terse as you feel comfortable with, depending on how closely you
conform to the expected conventions.
So, what does this new "vendor" foreign key do for us? Let's add some data and see.
Imagine the following two objects.
$v = Vendor->new(name => 'Acme')->save;
$p = Product->new(name => 'Kite')->save;
Note the use of the idiomatic way to create and then save an object in "one step." This
is possible because both the new and save methods return the object itself. Anyway, let's
link the two objects. One way to do it is to set the column values directly.
$p->vendor_id($v->id);
$p->save;
To use this technique, we must know which columns link to which other columns, of course.
But it works. We can see this by calling the method named after the foreign key itself:
"vendor()".
$v = $p->vendor; # Vendor object
print $v->name; # "Acme"
The "vendor()" method can be used to link the two objects as well. Let's start over and
try it that way:
$v = Vendor->new(name => 'Smith')->save;
$p = Product->new(name => 'Knife')->save;
$p->vendor($v);
$p->save;
print $p->vendor->name; # "Smith"
Remember that there is no column named "vendor" in the "products" table. There is a
"vendor_id" column, which has its own "vendor_id()" get/set method that accepts and
returns an integer value, but that's not what we're doing in the example above. Instead,
we're calling the "vendor()" method, which accepts and returns an entire "Vendor" object.
The "vendor()" method actually accepts several different kinds of arguments, all of which
it inflates into "Vendor" objects. An already-formed "Vendor" object was passed above,
but other formats are possible. Imagine a new product also made by Smith.
$p = Product->new(name => 'Rope')->save;
$p->vendor(name => 'Smith');
$p->save;
Here the arguments passed to the "vendor()" method are name/value pairs which will be used
to construct the appropriate "Vendor" object. Since "name" is a unique key in the
"vendors" table, the "Vendor" class can look up the existing vendor named "Smith" and
assign it to the "Rope" product.
If no vendor named "Smith" existed, one would have been created when the product was
saved. In this case, the save process would take place within a transaction (assuming the
database supports transactions) to ensure that both the product and vendor are created
successfully, or neither is.
The name/value pairs can also be provided in a reference to a hash.
$p = Product->new(name => 'Rope')->save;
$p->vendor({ name => 'Smith' });
$p->save;
Here's yet another argument format. Imagine that the "Acme" vendor id is 1.
$p = Product->new(name => 'Crate')->save;
$p->vendor(1);
$p->save;
print $p->vendor->name; # "Acme"
Like the name/value pair argument format, a primary key value will be used to construct
the appropriate object. (This only works if the foreign table has a single-column primary
key, of course.) And like before, if such an object doesn't exist, it will be created.
But in this case, if no existing vendor object had an "id" of 1, the attempt to create one
would have failed because the "name" column of the inserted row would have been null.
To summarize, the foreign key method can take arguments in these forms.
• An object of the appropriate class.
• Name/value pairs used to construct such an object.
• A reference to a hash containing name/value pairs used to construct such an object.
• A primary key value (but only if the foreign table has a single-column primary key).
In each case, the foreign object will be added to the database it if does not already
exist there. This all happens when the "parent" ("Product") object is saved. Until then,
nothing is stored in the database.
There's also another method created in response to the foreign key definition. This one
allows the foreign object to be deleted from the database.
print $p->vendor->name; # "Acme"
$p->delete_vendor();
$p->save; # The "Acme" vendor is deleted from the vendors table
Again, the actual database modification takes place when the parent object is saved. Note
that this operation will fail if any other rows in the "products" table still reference
the Acme vendor. And again, since this all takes place within a transaction (where
supported), the entire operation will fail or succeed as a single unit.
Finally, if we want to simply disassociate a product from its vendor, we can simply set
the vendor to undef.
$p->vendor(undef); # This product has no vendor
$p->save;
Setting the "vendor_id" column directly has the same effect, of course.
$p->vendor_id(undef); # set vendor_id = NULL
$p->save;
Before moving on to the next section, here's a brief note about auto-initialization and
foreign keys. Since foreign keys are a construct of the database itself, the auto-
initialization process can actually discover them and create the appropriate foreign key
metadata.
Since all of the column and table names are still in sync with the expected conventions,
the "Product" class can still be defined like this:
package Product;
use base 'My::DB::Object';
__PACKAGE__->meta->auto_initialize;
while retaining all of the abilities demonstrated above.
The perl_class_definition() method will produce the appropriate foreign key definitions,
as expected.
package Product;
use base 'My::DB::Object';
__PACKAGE__->meta->auto_initialize;
print __PACKAGE__->meta->perl_class_definition(indent => 2,
braces => 'bsd');
Here's the output.
package Product;
use base 'My::DB::Object';
__PACKAGE__->meta->setup
(
table => 'products',
columns =>
[
id => { type => 'integer', not_null => 1 },
name => { type => 'varchar', length => 255, not_null => 1 },
price => { type => 'numeric', default => '0.00',
not_null => 1, precision => 10, scale => 2 },
vendor_id => { type => 'integer' },
status => { type => 'varchar', default => 'inactive',
length => 128, not_null => 1 },
date_created => { type => 'timestamp', default => 'now()',
not_null => 1 },
release_date => { type => 'timestamp' },
],
primary_key_columns => [ 'id' ],
unique_keys => [ 'name' ],
allow_inline_column_values => 1,
foreign_keys =>
[
vendor =>
{
class => 'Vendor',
key_columns => { vendor_id => 'id' },
},
],
);
1;
Relationships
One-to-one and many-to-one relationships
Foreign keys are a database-native representation of a specific kind of inter-table
relationship. This concept can be further generalized to encompass other kinds of
relationships as well. But before we delve into that, let's consider the kind of
relationship that a foreign key represents.
In the product and vendor example in the previous section, each product has one vendor.
(Actually it can have zero or one vendor, since the "vendor_id" column allows NULL values.
But for now, we'll leave that aside.)
When viewed in terms of the participating tables, things look slightly different.
Earlier, we established that several products can have the same vendor. So the inter-
table relationship is actually this: many rows from the "products" table may refer to one
row from the "vendors" table.
Rose::DB::Object describes inter-table relationships from the perspective of a given table
by using the cardinality of the "local" table ("products") followed by the cardinality of
the "remote" table ("vendors"). The foreign key in the "products" table (and "Product"
class) therefore represents a "many to one" relationship.
If the relationship were different and each vendor was only allowed to have a single
product, then the relationship would be "one to one." Given only the foreign key
definition as it exists in the database, it's not possible to determine whether the
relationship is "many to one" or "one to one." The default is "many to one" because
that's the less restrictive choice.
To override the default, a relationship type string can be included in the foreign key
description.
foreign_keys =>
[
vendor =>
{
class => 'Vendor',
key_columns => { vendor_id => 'id' },
relationship_type => 'one to one',
},
],
(The "relationship_type" parameter may be shortened to "rel_type", if desired.)
Rose::DB::Object generalizes all inter-table relationships using a family of aptly named
relationship objects. Each inherits from the Rose::DB::Object::Metadata::Relationship
base class.
Even foreign keys are included under the umbrella of this concept. When foreign key
metadata is added to a Rose::DB::Object-derived class, a corresponding "many to one" or
"one to one" relationship is actually added as well. This relationship is simply a proxy
for the foreign key. It exists so that the set of relationship objects encompasses all
relationships, even those that correspond to foreign keys in the database. This makes
iterating over all relationships in a class a simple affair.
foreach my $rel (Product->meta->relationships)
{
print $rel->name, ': ', $rel->type, "\n";
}
For the "Product" class, the output is:
vendor: many to one
Given the two possible cardinalities, "many" and "one", it's easy to come up with a list
of all possible inter-table relationships. Here they are, listed with their corresponding
relationship object classes.
one to one - Rose::DB::Object::Metadata::Relationship::OneToOne
one to many - Rose::DB::Object::Metadata::Relationship::OneToMany
many to one - Rose::DB::Object::Metadata::Relationship::ManyToOne
many to many - Rose::DB::Object::Metadata::Relationship::ManyToMany
We've already seen that "one to one" and "many to one" relationships can be represented by
foreign keys in the database, but that's not a requirement. It's perfectly possible to
have either of those two kinds of relationships in a database that has no native support
for foreign keys. (MySQL using the MyISAM storage engine is a common example.)
If you find yourself using such a database, there's no reason to lie to your Perl classes
by adding foreign key metadata. Instead, simply add a relationship.
Here's an example of our "Product" class as it might exist on a database that does not
support foreign keys. (The "Product" class is getting larger now, so previously
established portions may be omitted from now on.)
package Product;
use base 'My::DB::Object';
__PACKAGE__->meta->setup
(
table => 'products',
columns => [... ],
pk_columns => 'id',
unique_key => 'name',
relationships =>
[
vendor =>
{
type => 'many to one',
class => 'Vendor',
column_map => { vendor_id => 'id' },
},
],
);
They syntax and semantics are similar to those described for foreign keys. The only
slight differences are the names and types of parameters accepted by relationship objects.
In the example above, a "many to one" relationship named "vendor" is set up. As
demonstrated before, this definition can be reduced much further, allowing the convention
manager to fill in the details. But unlike the case with the foreign key definition,
where only the name was supplied, we must provide the relationship type as well.
relationships => [ vendor => { type => 'many to one' } ],
There's an even more convenient shorthand for that:
relationships => [ vendor => 'many to one' ],
(Again, this all depends on naming the tables, classes, and columns in accordance with the
expectations of the convention manager.) The resulting "vendor()" and "delete_vendor()"
methods behave exactly the same as the methods created on behalf of the foreign key
definition.
One-to-many relationships
Now let's explore the other two relationship types. We'll start with "one to many" by
adding region-specific pricing to our products. First, we'll need a "prices" table.
CREATE TABLE prices
(
id SERIAL NOT NULL PRIMARY KEY,
product_id INT NOT NULL REFERENCES products (id),
region CHAR(2) NOT NULL DEFAULT 'US',
price DECIMAL(10,2) NOT NULL DEFAULT 0.00,
UNIQUE(product_id, region)
);
This table needs a corresponding Rose::DB::Object-derived class, of course.
package Price;
use base 'My::DB::Object';
__PACKAGE__->meta->setup
(
table => 'prices',
columns =>
[
id => { type => 'serial', not_null => 1 },
product_id => { type => 'int', not_null => 1 },
region => { type => 'char', length => 2, not_null => 1 },
price =>
{
type => 'decimal',
precision => 10,
scale => 2,
not_null => 1,
default => 0.00
},
],
primary_key_columns => [ 'id' ],
unique_key => [ 'product_id', 'region' ],
foreign_keys =>
[
product =>
{
class => 'Product',
key_columns => { product_id => 'id' },
},
],
);
The "price" column can be removed from the "products" table.
ALTER TABLE products DROP COLUMN price;
Finally, the "Product" class needs to be modified to reference the "prices" table.
package Product;
use base 'My::DB::Object';
use Price;
use Vendor;
__PACKAGE__->meta->setup
(
table => 'products',
columns => [ ... ],
pk_columns => 'id',
unique_key => 'name',
foreign_keys =>
[
vendor =>
{
class => 'Vendor',
key_columns => { vendor_id => 'id' },
},
],
relationships =>
[
prices =>
{
type => 'one to many',
class => 'Price',
column_map => { id => 'product_id' },
},
],
);
Note that both the column map for the "one to many" relationship and the key columns for
the foreign key connect "local" columns to "foreign" columns.
The "vendor_id" column in the local table ("products") is connected to the "id" column in
the foreign table ("vendors"):
vendor =>
{
key_columns => { vendor_id => 'id' },
...
}
The "id" column in the local table ("products") is connected to the "product_id" column in
the foreign table ("prices"):
prices =>
{
column_map => { id => 'product_id' },
...
}
This is all from the perspective of the class in which the definitions appear. Note that
things are reversed in the "Price" class.
package Price;
...
__PACKAGE__->meta->setup
(
...
foreign_keys =>
[
product =>
{
class => 'Product',
key_columns => { product_id => 'id' },
},
],
);
Here, the "product_id" column in the local table ("prices") is connected to the "id"
column in the foreign table ("products").
The methods created by "... to many" relationships behave much like their "... to one" and
foreign key counterparts. The main difference is that lists or references to arrays of
the previously described argument formats are also acceptable, while name/value pairs
outside of a hashref are not.
Here's a list of argument types accepted by "many to one" methods like "prices".
• A list or reference to an array of objects of the appropriate class.
• A list or reference to an array of hash references containing name/value pairs used to
construct such objects.
• A list or reference to an array of primary key values (but only if the foreign table
has a single-column primary key).
Setting a new list of prices will delete all the old prices. As with foreign keys, any
actual database modification happens when the parent object is saved. Here are some
examples.
$p = Product->new(name => 'Kite');
$p->prices({ price => 1.23, region => 'US' },
{ price => 4.56, region => 'UK' });
$p->save; # database is modified here
# US: 1.23, UK: 4.56
print join(', ', map { $_->region . ': ' . $_->price } $p->prices);
New prices can be added without deleting and resetting the entire list:
# Add two prices to the existing list
$p->add_prices({ price => 7.89, region => 'DE' },
{ price => 1.11, region => 'JP' });
$p->save; # database is modified here
Passing a reference to an empty array will cause all the prices to be deleted:
$p->prices([]); # delete all prices associated with this product
$p->save; # database is modified here
Cascading delete
Deleting a product now becomes slightly more interesting. The naive approach fails.
$p->delete; # Fatal error!
# DBD::Pg::st execute failed: ERROR: update or delete on "products"
# violates foreign key constraint "prices_product_id_fkey" on
# "prices"
# DETAIL: Key (id)=(12345) is still referenced from table "prices".
Since rows in the "prices" table now link to rows in the "products" table, a product
cannot be deleted until all of the prices that refer to it are also deleted. There are a
few ways to deal with this.
The best solution is to add a trigger to the "products" table itself in the database that
makes sure to delete any associated prices before deleting a product. This change will
allow the naive approach shown above to work correctly.
A less robust solution is necessary if your database does not support triggers. One such
solution is to manually delete the prices before deleting the product. This can be done
in several ways. The prices can be deleted directly, like this.
foreach my $price ($p->prices)
{
$price->delete; # Delete all associated prices
}
$p->delete; # Now it's safe to delete the product
The list of prices for the product can also be set to an empty list, which will have the
effect of deleting all associated prices when the product is saved.
$p->prices([]);
$p->save; # All associated prices deleted here
$p->delete; # Now it's safe to delete the product
Finally, the delete() method can actually automate this process, and do it all inside a
transaction as well.
$p->delete(cascade => 1); # Delete all associated rows too
Again, the recommended approach is to use triggers inside the database itself. But if
necessary, these other approaches will work too.
Many-to-many relationships
The final relationship type is the most complex. In a "many to many" relationship, a
single row in table A may be related to multiple rows in table B, while a single row in
table B may also be related to multiple rows in table A. (Confused? A concrete example
will follow shortly.)
This kind of relationship involves three tables instead of just two. The "local" and
"foreign" tables, familiar from the other relationship types described above, still exist,
but now there's a third table that connects rows from those two tables. This third table
is called the "mapping table," and the Rose::DB::Object-derived class that fronts it is
called the "map class."
Let's add such a relationship to our growing family of classes. Imagine that each product
may come in several colors. Right away, both the "one to one" and "many to one"
relationship types are eliminated since they can only provide a single color for any given
product.
But wait, isn't a "one to many" relationship suitable? After all, one product may have
many colors. Unfortunately, such a relationship is wasteful in this case. Let's see why.
Imagine a "colors" table like this.
CREATE TABLE colors
(
id SERIAL NOT NULL PRIMARY KEY,
name VARCHAR(255) NOT NULL,
product_id INT NOT NULL REFERENCES products (id)
);
Here's a simple "Color" class to front it.
package Color;
use base 'My::DB::Object';
__PACKAGE__->meta->setup
(
table => 'colors',
columns =>
[
id => { type => 'serial', primary_key => 1, not_null => 1 },
name => { type => 'varchar', length => 255, not_null => 1 },
product_id => { type => 'int', not_null => 1 },
],
foreign_keys =>
[
product =>
{
class => 'Product',
key_columns => { product_id => 'id' },
},
],
);
Finally, let's add the "one to many" relationship to the "Product" class.
package Product;
use base 'My::DB::Object';
__PACKAGE__->meta->setup
(
...
relationships =>
[
colors =>
{
type => 'one to many',
class => 'Color',
column_map => { id => 'product_id' },
},
...
],
);
It works as expected.
$p1 = Product->new(id => 10,
name => 'Sled',
colors =>
[
{ name => 'red' },
{ name => 'green' },
]);
$p1->save;
$p2 = Product->new(id => 20,
name => 'Kite',
colors =>
[
{ name => 'blue' },
{ name => 'green' },
{ name => 'red' },
]);
$p2->save;
But now look at the contents of the "colors" table in the database.
mydb=# select * from colors;
id | name | product_id
----+-------+------------
1 | red | 10
2 | green | 10
3 | blue | 20
4 | green | 20
5 | red | 20
Notice that the colors "green" and "red" appear twice. Now imagine that there are 50,000
products. What are the odds that there will be more than a few colors in common among
them?
This is a poor database design. To fix it, we must recognize that colors will be shared
among products, since the set of possible colors is relatively small compared to the set
of possible products. One product may have many colors, but one color may also belong to
many products. And there you have it: a textbook "many to many" relationship.
Let's redesign this relationship in "many to many" form, starting with a new version of
the "colors" table.
CREATE TABLE colors
(
id SERIAL NOT NULL PRIMARY KEY,
name VARCHAR(255) NOT NULL,
UNIQUE(name)
);
Since each color will now appear only once in this table, we can make the "name" column a
unique key.
Here's the new "Color" class.
package Color;
use base 'My::DB::Object';
__PACKAGE__->meta->setup
(
table => 'colors',
columns =>
[
id => { type => 'serial', primary_key => 1, not_null => 1 },
name => { type => 'varchar', length => 255, not_null => 1 },
],
unique_key => 'name',
);
Since the "colors" table no longer has a foreign key that points to the "products" table,
we need some way to connect the two tables: a mapping table.
CREATE TABLE product_color_map
(
product_id INT NOT NULL REFERENCES products (id),
color_id INT NOT NULL REFERENCES colors (id),
PRIMARY KEY(product_id, color_id)
);
Note that there's no reason for a separate primary key column in this table. We'll use a
two-column primary key instead.
Here's the map class.
package ProductColorMap;
use base 'My::DB::Object';
__PACKAGE__->meta->setup
(
table => 'product_color_map',
columns =>
[
product_id => { type => 'int', not_null => 1 },
color_id => { type => 'int', not_null => 1 },
],
primary_key_columns => [ 'product_id', 'color_id' ],
foreign_keys =>
[
product =>
{
class => 'Product',
key_columns => { product_id => 'id' },
},
color =>
{
class => 'Color',
key_columns => { color_id => 'id' },
},
],
);
It's important that the map class have either a foreign key or a "many to one"
relationship pointing to each of the tables that it maps between. In this case, there are
two foreign keys.
Finally, here's the "many to many" relationship definition in the "Product" class.
package Product;
...
__PACKAGE__->meta->setup
(
...
relationships =>
[
colors =>
{
type => 'many to many',
map_class => 'ProductColorMap'
map_from => 'product',
map_to => 'color',
},
...
],
);
Note that only the map class needs to be "use"d in the "Product" class. The relationship
definition specifies the name of the map class, and (optionally) the names of the foreign
keys or "many to one" relationships in the map class that connect the two tables.
In most cases, these two parameters ("map_from" and "map_to") are unnecessary.
Rose::DB::Object will figure out what to do given only the map class, so long as there's
no ambiguity in the mapping table.
In this case, there is no ambiguity, so the relationship definition can be shortened to
this.
use Product;
...
__PACKAGE__->meta->setup
(
relationships =>
[
colors =>
{
type => 'many to many',
map_class => 'ProductColorMap'
},
],
...
);
In fact, since the map table is named according to the default conventions, it can be
shortened even further.
use Product;
...
__PACKAGE__->meta->setup
(
relationships =>
[
colors => { type => 'many to many' },
...
],
...
);
And further still:
use Product;
...
__PACKAGE__->meta->setup
(
relationships =>
[
colors => 'many to many',
...
],
...
);
(Classes can be shortened even more absurdly when auto-initialization is combined with the
convention manager. See the convention manager documentation for an example.)
Now let's revisit the example code.
$p1 = Product->new(id => 10,
name => 'Sled',
colors =>
[
{ name => 'red' },
{ name => 'green' }
]);
$p1->save;
$p2 = Product->new(id => 20,
name => 'Kite',
colors =>
[
{ name => 'blue' },
{ name => 'green' },
{ name => 'red' },
]);
$p2->save;
The code works as expected, but the database now looks much nicer.
mydb=# select * from colors;
id | name
----+-------
1 | red
2 | green
3 | blue
mydb=# select * from product_color_map;
product_id | color_id
------------+----------
10 | 1
10 | 2
20 | 3
20 | 2
20 | 1
Each color appears only once, and the mapping table handles all the connections between
the "colors" and "products" tables.
The "many to many" "colors" method works much like the "one to many" "prices" method
described earlier. The valid argument formats are the same.
• A list or reference to an array of objects of the appropriate class.
• A list or reference to an array of hash references containing name/value pairs used to
construct such objects.
• A list or reference to an array of primary key values (but only if the foreign table
has a single-column primary key).
The database modification behavior is also the same, with changes happening when the
"parent" object is saved.
$p = Product->new(id => 123)->load;
$p->colors({ name => 'green' },
{ name => 'blue' });
$p->save; # database is modified here
Setting the list of colors replaces the old list, but in the case of a "many to many"
relationship, only the map records are deleted.
$p = Product->new(id => 123)->load;
$p->colors({ name => 'pink' },
{ name => 'orange' });
# Delete old rows in the mapping table and create new ones
$p->save;
New colors can be added without deleting and resetting the entire list:
# Add two colors to the existing list
$p->add_colors({ name => 'gray' },
{ name => 'red' });
$p->save; # database is modified here
Passing a reference to an empty array will remove all colors associated with a particular
product by deleting all the mapping table entries.
$p->colors([]);
$p->save; # all mapping table entries for this product deleted here
Finally, the same caveats described earlier about deleting products that have associated
prices apply to colors as well. Again, I recommend using a trigger in the database to
handle this, but Rose::DB::Object's cascading delete feature will work in a pinch.
# Delete all associated rows in the prices table, plus any
# rows in the product_color_map table, before deleting the
# row in the products table.
$p->delete(cascade => 1);
Relationship code summary
To summarize this exploration of inter-table relationships, here's a terse summary of the
current state of our Perl classes, and the associated database tables.
For the sake of brevity, I've chosen to use the shorter versions of the foreign key and
relationship definitions in the Perl classes shown below. Just remember that this only
works when your tables, columns, and classes are named according to the expected
conventions.
First, the database schema.
CREATE TABLE vendors
(
id SERIAL NOT NULL PRIMARY KEY,
name VARCHAR(255) NOT NULL,
UNIQUE(name)
);
CREATE TABLE products
(
id SERIAL NOT NULL PRIMARY KEY,
name VARCHAR(255) NOT NULL,
vendor_id INT REFERENCES vendors (id),
status VARCHAR(128) NOT NULL DEFAULT 'inactive'
CHECK(status IN ('inactive', 'active', 'defunct')),
date_created TIMESTAMP NOT NULL DEFAULT NOW(),
release_date TIMESTAMP,
UNIQUE(name)
);
CREATE TABLE prices
(
id SERIAL NOT NULL PRIMARY KEY,
product_id INT NOT NULL REFERENCES products (id),
region CHAR(2) NOT NULL DEFAULT 'US',
price DECIMAL(10,2) NOT NULL DEFAULT 0.00,
UNIQUE(product_id, region)
);
CREATE TABLE colors
(
id SERIAL NOT NULL PRIMARY KEY,
name VARCHAR(255) NOT NULL,
UNIQUE(name)
);
CREATE TABLE product_color_map
(
product_id INT NOT NULL REFERENCES products (id),
color_id INT NOT NULL REFERENCES colors (id),
PRIMARY KEY(product_id, color_id)
);
Now the Perl classes. Remember that these must each be in their own ".pm" files, despite
appearing in one contiguous code snippet below.
package Vendor;
use base 'My::DB::Object';
__PACKAGE__->meta->setup
(
table => 'vendors',
columns =>
[
id => { type => 'serial', primary_key => 1, not_null => 1 },
name => { type => 'varchar', length => 255, not_null => 1 },
],
unique_key => 'name',
);
1;
package Product;
use base 'My::DB::Object';
__PACKAGE__->meta->setup
(
table => 'products',
columns =>
[
id => { type => 'integer', not_null => 1 },
name => { type => 'varchar', length => 255, not_null => 1 },
vendor_id => { type => 'int' },
status => { type => 'varchar', default => 'inactive',
length => 128, not_null => 1 },
date_created => { type => 'timestamp', not_null => 1,
default => 'now()' },
release_date => { type => 'timestamp' },
]
primary_key_columns => 'id',
unique_key => 'name',
allow_inline_column_values => 1,
relationships =>
[
prices => 'one to many',
colors => 'many to many',
]
);
1;
package Price;
use Product;
use base 'My::DB::Object';
__PACKAGE__->meta->setup
(
table => 'prices',
columns =>
[
id => { type => 'serial', primary_key => 1, not_null => 1 },
product_id => { type => 'int', not_null => 1 },
region => { type => 'char', length => 2, not_null => 1 },
price =>
{
type => 'decimal',
precision => 10,
scale => 2,
not_null => 1,
default => 0.00
},
],
unique_key => [ 'product_id', 'region' ],
foreign_key => [ 'product' ],
);
1;
package Color;
use base 'My::DB::Object';
__PACKAGE__->meta->setup
(
table => 'colors',
columns =>
[
id => { type => 'serial', primary_key => 1, not_null => 1 },
name => { type => 'varchar', length => 255, not_null => 1 },
],
unique_key => 'name',
);
1;
package ProductColorMap;
use base 'My::DB::Object';
__PACKAGE__->meta->setup
(
table => 'product_color_map',
columns =>
[
product_id => { type => 'int', not_null => 1 },
color_id => { type => 'int', not_null => 1 },
],
pk_columns => [ 'product_id', 'color_id' ],
foreign_keys => [ 'product', 'color' ],
);
1;
The loader
If the code above still looks like too much work to you, try letting
Rose::DB::Object::Loader do it all for you. Given the database schema shown above, the
suite of associated Perl classes could have been created automatically with a single
method call.
$loader =
Rose::DB::Object::Loader->new(db => Rose::DB->new,
class_prefix => 'My::');
$loader->make_classes;
If you want to see what the loader did for you, catch the return value of the make_classes
method (which will be a list of class names) and then ask each class to print its perl
equivalent.
@classes = $loader->make_classes;
foreach my $class (@classes)
{
if($class->isa('Rose::DB::Object'))
{
print $class->meta->perl_class_definition(braces => 'bsd',
indent => 2), "\n";
}
else # Rose::DB::Object::Manager subclasses
{
print $class->perl_class_definition, "\n";
}
}
You can also ask the loader to make actual Perl modules (that is, a set of actual *.pm
files in the file system) by calling the aptly named make_modules method.
The code created by the loader is shown below. Compare it to the manually created Perl
code shown above and you'll see that it's nearly identical. Again, careful table name
choices really help here. Do what the convention manager expects (or write your own
convention manager subclass that does what you expect) and automation like this can work
very well.
package My::Color;
use strict;
use base qw(My::DB::Object::Base1);
__PACKAGE__->meta->setup
(
table => 'colors',
columns =>
[
id => { type => 'integer', not_null => 1 },
name => { type => 'varchar', length => 255, not_null => 1 },
],
primary_key_columns => [ 'id' ],
unique_keys => [ 'name' ],
relationships =>
[
products =>
{
column_map => { color_id => 'id' },
foreign_class => 'My::Product',
map_class => 'My::ProductColorMap',
map_from => 'color',
map_to => 'product',
type => 'many to many',
},
],
);
1;
package My::Color::Manager;
use base qw(Rose::DB::Object::Manager);
use My::Color;
sub object_class { 'My::Color' }
__PACKAGE__->make_manager_methods('colors');
1;
package My::Price;
use strict;
use base qw(My::DB::Object::Base1);
__PACKAGE__->meta->setup
(
table => 'prices',
columns =>
[
id => { type => 'integer', not_null => 1 },
product_id => { type => 'integer', not_null => 1 },
region => { type => 'character', default => 'US', length => 2,
not_null => 1 },
price => { type => 'numeric', default => '0.00', not_null => 1,
precision => 10, scale => 2 },
],
primary_key_columns => [ 'id' ],
unique_key => [ 'product_id', 'region' ],
foreign_keys =>
[
product =>
{
class => 'My::Product',
key_columns =>
{
product_id => 'id',
},
},
],
);
1;
package My::Price::Manager;
use base qw(Rose::DB::Object::Manager);
use My::Price;
sub object_class { 'My::Price' }
__PACKAGE__->make_manager_methods('prices');
1;
package My::ProductColorMap;
use strict;
use base qw(My::DB::Object::Base1);
__PACKAGE__->meta->setup
(
table => 'product_color_map',
columns =>
[
product_id => { type => 'integer', not_null => 1 },
color_id => { type => 'integer', not_null => 1 },
],
primary_key_columns => [ 'product_id', 'color_id' ],
foreign_keys =>
[
color =>
{
class => 'My::Color',
key_columns =>
{
color_id => 'id',
},
},
product =>
{
class => 'My::Product',
key_columns =>
{
product_id => 'id',
},
},
],
);
1;
package My::ProductColorMap::Manager;
use base qw(Rose::DB::Object::Manager);
use My::ProductColorMap;
sub object_class { 'My::ProductColorMap' }
__PACKAGE__->make_manager_methods('product_color_map');
1;
package My::ProductColor;
use strict;
use base qw(My::DB::Object::Base1);
__PACKAGE__->meta->setup
(
table => 'product_colors',
columns =>
[
id => { type => 'integer', not_null => 1 },
product_id => { type => 'integer', not_null => 1 },
color_code => { type => 'character', length => 3, not_null => 1 },
],
primary_key_columns => [ 'id' ],
);
1;
package My::ProductColor::Manager;
use base qw(Rose::DB::Object::Manager);
use My::ProductColor;
sub object_class { 'My::ProductColor' }
__PACKAGE__->make_manager_methods('product_colors');
1;
package My::Product;
use strict;
use base qw(My::DB::Object::Base1);
__PACKAGE__->meta->setup
(
table => 'products',
columns =>
[
id => { type => 'integer', not_null => 1 },
name => { type => 'varchar', length => 255, not_null => 1 },
price => { type => 'numeric', default => '0.00', not_null => 1,
precision => 10, scale => 2 },
vendor_id => { type => 'integer' },
status => { type => 'varchar', default => 'inactive',
length => 128, not_null => 1 },
date_created => { type => 'timestamp', default => 'now()',
not_null => 1 },
release_date => { type => 'timestamp' },
],
primary_key_columns => [ 'id' ],
unique_keys => [ 'name' ],
allow_inline_column_values => 1,
foreign_keys =>
[
vendor =>
{
class => 'My::Vendor',
key_columns =>
{
vendor_id => 'id',
},
},
],
relationships =>
[
colors =>
{
column_map => { product_id => 'id' },
foreign_class => 'My::Color',
map_class => 'My::ProductColorMap',
map_from => 'product',
map_to => 'color',
type => 'many to many',
},
prices =>
{
class => 'My::Price',
key_columns => { id => 'product_id' },
type => 'one to many',
},
],
);
1;
package My::Product::Manager;
use base qw(Rose::DB::Object::Manager);
use My::Product;
sub object_class { 'My::Product' }
__PACKAGE__->make_manager_methods('products');
1;
package My::Vendor;
use strict;
use base qw(My::DB::Object::Base1);
__PACKAGE__->meta->setup
(
table => 'vendors',
columns =>
[
id => { type => 'integer', not_null => 1 },
name => { type => 'varchar', length => 255, not_null => 1 },
],
primary_key_columns => [ 'id' ],
unique_keys => [ 'name' ],
relationships =>
[
products =>
{
class => 'My::Product',
key_columns => { id => 'vendor_id' },
type => 'one to many',
},
],
);
1;
package My::Vendor::Manager;
use base qw(Rose::DB::Object::Manager);
use My::Vendor;
sub object_class { 'My::Vendor' }
__PACKAGE__->make_manager_methods('vendors');
1;
Auto-joins and other Manager features
The "Product::Manager" class we created earlier is deceptively simple. Setting it up can
actually be reduced to a one-liner, but it provides a rich set of features.
The basics demonstrated earlier cover most kinds of single-table SELECT statements. But
as the "Product" class has become more complex, linking to other objects via foreign keys
and other relationships, selecting rows from just the "products" table has become a lot
less appealing. What good is it to retrieve hundreds of products in a single query when
you then have to execute hundreds of individual queries to get the prices of those
products?
This is what SQL JOINs were made for: selecting related rows from multiple tables
simultaneously. Rose::DB::Object::Manager supports a two kinds of joins. The interface
to this functionality is presented in terms of objects via the "require_objects" and
"with_objects" parameters to the get_objects() method.
Both parameters expect a list of foreign key or relationship names. The "require_objects"
parameters will use an "inner join" to fetch related objects, while the "with_objects"
parameter will perform an "outer join."
If you're unfamiliar with these terms, it's probably a good idea to learn about them from
a good SQL book or web tutorial. But even if you've never written an SQL JOIN by hand,
there's not much you need to understand in order to use your manager class effectively.
The rule of thumb is simple. When you want each and every object returned by your query
to have a particular related object, then use the "require_objects" parameter. But if you
do not want to exclude objects even if they do not have a particular related object
attached to them yet, then use the "with_objects" parameter.
Sometimes, this decision is already made for you by the table structure. For example,
let's modify the "products" table in order to require that every single product has a
vendor. To do so, we'll change the "vendor_id" column definition from this:
vendor_id INT REFERENCES vendors (id)
to this:
vendor_id INT NOT NULL REFERENCES vendors (id)
Now it's impossible for a product to have a NULL "vendor_id". And since our database
enforces referential integrity, it's also impossible for the "vendor_id" column to have a
value that does not refer to the "id" of an existing row in the "vendors" table.
While the "with_objects" parameter could technically be used to fetch "Product"s with
their associated "Vendor" objects, it would be wasteful. (Outer joins are often less
efficient than inner joins.) The table structure basically dictates that the
"require_objects" parameter be used when fetching "Product"s with their "Vendor"s.
Here's how such a query could actually look.
$products =
Product::Manager->get_products(
query =>
[
name => { like => 'Kite%' },
id => { gt => 15 },
]
require_objects => [ 'vendor' ],
sort_by => 'name');
Recall that the name of the foreign key that connects a product to its vendor is "vendor".
Thus, the value of the "require_objects" parameter is a reference to an array containing
this name.
Getting information about each product's vendor now no longer requires additional database
queries.
foreach my $product (@$products)
{
# This does not hit the database at all
print $product->vendor->name, "\n";
}
For the SQL-inclined, the actual query run looks something like this.
SELECT
t1.date_created,
t1.id,
t1.name,
t1.release_date,
t1.status,
t1.vendor_id,
t2.id,
t2.name
FROM
products t1,
vendors t2
WHERE
t1.id >= 16 AND
t1.name LIKE 'Kite%' AND
t1.vendor_id = t2.id
ORDER BY t1.name
As you can see, the query includes "tN" aliases for each table. This is important because
columns in separate tables often have identical names. For example, both the "products"
and the "vendors" tables have columns named "id" and "name".
In the query, you'll notice that the "name => { like => 'Kite%' }" argument ended up
filtering on the product name rather than the vendor name. This is intentional. Any
unqualified column name that is ambiguous is considered to belong to the "primary" table
("products", in this case).
The "tN" numbering is deterministic. The primary table is always "t1", and secondary
tables are assigned ascending numbers starting from there. You can find a full
explanation of the numbering rules in the Rose::DB::Object::Manager documentation.
In the example above, if we wanted to filter and sort on the vendor name instead, we could
do this.
$products =
Product::Manager->get_products(
query =>
[
't2.name' => { like => 'Acm%' },
id => { gt => 15 },
]
require_objects => [ 'vendor' ],
sort_by => 't2.name');
But that's not the only option. There are several ways to disambiguate a query clause.
The column name can also be qualified by prefixing it with a relationship name.
$products =
Product::Manager->get_products(
query =>
[
'vendor.name' => { like => 'Acm%' },
id => { gt => 15 },
]
require_objects => [ 'vendor' ],
sort_by => 'vendor.name');
The actual table name itself can also be used (although I do not recommend this practice
since you will have to change all such usage instances if you ever rename the table).
$products =
Product::Manager->get_products(
query =>
[
'vendors.name' => { like => 'Acm%' },
id => { gt => 15 },
]
require_objects => [ 'vendor' ],
sort_by => 'vendors.name');
Now let's see an example of the "with_objects" parameter in action. Each "Product" has
zero or more "Price"s. Let's fetch products with all their associated prices. And
remember that some of these products may have no prices at all.
$products =
Product::Manager->get_products(
query =>
[
name => { like => 'Kite%' },
id => { gt => 15 },
],
with_objects => [ 'prices' ],
sort_by => 'name');
Again, since the name of the "one to many" relationship that connects a product to its
prices is "prices", this is the value use in the "with_objects" parameter. The SQL looks
something like this:
SELECT
t1.date_created,
t1.id,
t1.name,
t1.release_date,
t1.status,
t1.vendor_id,
t2.id,
t2.price,
t2.product_id,
t2.region
FROM
products t1
LEFT OUTER JOIN prices t2 ON(t1.id = t2.product_id)
WHERE
t1.id > 15 AND
t1.name LIKE 'Kite%'
ORDER BY t1.name
Fetching products with both their vendors and prices (if any) is straightforward. Just
use the "require_objects" parameter for the vendors and the "with_objects" parameter for
the prices.
$products =
Product::Manager->get_products(
query =>
[
name => { like => 'Kite%' },
id => { gt => 15 },
],
require_objects => [ 'vendor' ],
with_objects => [ 'prices' ],
sort_by => 'name');
The resulting SQL is what you'd expect.
SELECT
t1.date_created,
t1.id,
t1.name,
t1.release_date,
t1.status,
t1.vendor_id,
t2.id,
t2.price,
t2.product_id,
t2.region,
t3.id,
t3.name
FROM
products t1
JOIN vendors t3 ON (t1.vendor_id = t3.id)
LEFT OUTER JOIN prices t2 ON(t1.id = t2.product_id)
WHERE
t1.id > 15 AND
t1.name LIKE 'Kite%'
ORDER BY t1.name
Each "Product" also has zero or more "Color"s which are related to it through a mapping
table (fronted by the "ProductColorMap" class, but we don't need to know that). The
"with_objects" parameter can handle that as well.
$products =
Product::Manager->get_products(
query =>
[
name => { like => 'Kite%' },
id => { gt => 15 },
],
with_objects => [ 'colors' ],
sort_by => 'name');
The resulting SQL is a bit more complex.
SELECT
t1.date_created,
t1.id,
t1.name,
t1.release_date,
t1.status,
t1.vendor_id,
t3.id,
t3.name
FROM
products t1
LEFT OUTER JOIN product_color_map t2 ON(t2.product_id = t1.id)
LEFT OUTER JOIN colors t3 ON(t2.color_id = t3.id)
WHERE
t1.id > 15 AND
t1.name LIKE 'Kite%'
Again, combinations are straightforward. Let's fetch products with their vendors and
colors.
$products =
Product::Manager->get_products(
query =>
[
name => { like => 'Kite%' },
id => { gt => 15 },
],
require_objects => [ 'vendor' ],
with_objects => [ 'colors' ],
sort_by => 'name');
Now the SQL is starting to get a bit hairy.
SELECT
t1.id,
t1.name,
t1.vendor_id,
t3.code,
t3.name,
t4.id,
t4.name,
t4.region_id
FROM
products t1
JOIN vendors t4 ON (t1.vendor_id = t4.id)
LEFT OUTER JOIN product_colors t2 ON (t2.product_id = t1.id)
LEFT OUTER JOIN colors t3 ON (t2.color_code = t3.code)
WHERE
t1.id > 15 AND
t1.name LIKE 'Kite%'
Anyone who knows SQL well will recognize that there is a danger lurking when combining
JOINs. Multiple joins that each fetch multiple rows can result in a geometric explosion
of rows returned by the database. For example, the number of rows returned when fetching
products with their associated prices and colors would be:
<number of matching products> x
<number of prices for each product> x
<number of colors for each product>
That number can get very large, very fast if products have many prices, colors, or both.
(The last two terms in the multiplication maybe switched, depending on the order of the
actual JOIN clauses, but the results are similar.) And the problem only gets worse as the
number of objects related by "... to many" relationships increases.
That said, Rose::DB::Object::Manager does allow multiple objects related by "... to many"
relationships to be fetched simultaneously. But it requires the developer to supply the
"multi_many_ok" parameter with a true value as a form of confirmation. "Yes, I know the
risks, but I want to do it anyway."
As an example, let's try fetching products with their associated prices, colors, and
vendors. To do so, we'll have to include the "multi_many_ok" parameter.
$products =
Product::Manager->get_products(
query =>
[
name => { like => 'Kite%' },
id => { gt => 15 },
],
require_objects => [ 'vendor' ],
with_objects => [ 'colors', 'prices' ],
multi_many_ok => 1,
sort_by => 'name');
Here's the SQL.
SELECT
t1.id,
t1.name,
t1.vendor_id,
t3.code,
t3.name,
t4.price_id,
t4.product_id,
t4.region,
t4.price,
t5.id,
t5.name,
t5.region_id
FROM
products t1
JOIN vendors t5 ON (t1.vendor_id = t5.id)
LEFT OUTER JOIN product_colors t2 ON (t2.product_id = t1.id)
LEFT OUTER JOIN colors t3 ON (t2.color_code = t3.code)
LEFT OUTER JOIN prices t4 ON (t1.id = t4.product_id)
WHERE
t1.id > 15 AND
t1.name LIKE 'Kite%'
ORDER BY t1.name
It's questionable whether this five-way join will be faster than doing a four- or three-
way join and then fetching the other information after the fact, with separate queries.
It all depends on the number of rows expected to match. Only you know your data. You
must choose the most efficient query that suits your needs.
Moving beyond even the example above, it's possible to chain foreign key or relationship
names to an arbitrary depth. For example, imagine that each "Vendor" has a "Region"
related to it by a foreign key named "region". The following call will get region
information for each product's vendor, filtering on the region name.
$products =
Product::Manager->get_products(
query =>
[
'vendor.region.name' => 'UK',
'name' => { like => 'Kite%' },
'id' => { gt => 15 },
],
require_objects => [ 'vendor.region' ],
with_objects => [ 'colors', 'prices' ],
multi_many_ok => 1,
sort_by => 'name');
The SQL would now look something like this.
SELECT
t1.id,
t1.name,
t1.vendor_id,
t3.code,
t3.name,
t4.price_id,
t4.product_id,
t4.region,
t4.price,
t5.id,
t5.name,
t5.region_id,
t6.id,
t6.name
FROM
products t1
JOIN (vendors t5 JOIN regions t6 ON (t5.region_id = t6.id))
ON (t1.vendor_id = t5.id)
LEFT OUTER JOIN product_colors t2 ON (t2.product_id = t1.id)
LEFT OUTER JOIN colors t3 ON (t2.color_code = t3.code)
LEFT OUTER JOIN prices t4 ON (t1.id = t4.product_id)
WHERE
t1.id > 15 AND
t1.name LIKE 'Kite%' AND
t6.name = 'UK'
ORDER BY t1.name
The same caveat about performance and the potential explosion of redundant data when
JOINing across multiple "... to many" relationships also applies to the "chained"
selectors demonstrated above--even more so, in fact, as the depth of the chain increases.
That said, it's usually safe to go a few levels deep into "... to one" relationships when
using the "require_objects" parameter.
Finally, it's also possible to load a single product with all of its associated foreign
objects. The load() method accepts a "with" parameter that takes a list of foreign key
and relationship names.
$product = Product->new(id => 1234);
$product->load(with => [ 'vendor', 'colors', 'prices' ]);
The same "multi many" caveats apply, but the "multi_many_ok" parameter is not required in
this case. The assumption is that a single object won't have too many related objects.
But again, only you know your data, so be careful.
Wrap-up
I hope you've learned something from this tutorial. Although it is by no means a complete
tour of all of the features of Rose::DB::Object, it does hit most of the highlights. This
tutorial will likely expand in the future, and a separate document describing the various
ways that Rose::DB::Object can be extended is also planned. For now, there is a brief
overview that was pulled from the Rose::DB::Object mailing list in the wiki.
https://github.com/siracusa/rose/wiki/Extending-Rose%3A%3ADB%3A%3AObject
See the support section below for more information on the mailing list.
DEVELOPMENT POLICY
The Rose development policy applies to this, and all "Rose::*" modules. Please install
Rose from CPAN and then run ""perldoc Rose"" for more information.
SUPPORT
Any Rose::DB::Object questions or problems can be posted to the Rose::DB::Object mailing
list. To subscribe to the list or view the archives, go here:
<http://groups.google.com/group/rose-db-object>
Although the mailing list is the preferred support mechanism, you can also email the
author (see below) or file bugs using the CPAN bug tracking system:
<http://rt.cpan.org/NoAuth/Bugs.html?Dist=Rose-DB-Object>
There's also a wiki and other resources linked from the Rose project home page:
<http://rosecode.org>
AUTHOR
John C. Siracusa (siracusa@gmail.com)
COPYRIGHT
Copyright (c) 2007 by John C. Siracusa. All rights reserved. This program is free
software; you can redistribute it and/or modify it under the same terms as Perl itself.