Six Apart Ltd. > Data-ObjectDriver-0.09 > Data::ObjectDriver



Annotate this POD (5)



New  9
Open  2
View/Report Bugs
Module Version: 0.09   Source  


Data::ObjectDriver - Simple, transparent data interface, with caching


    ## Set up your database driver code.
    package FoodDriver;
    sub driver {
            dsn      => 'dbi:mysql:dbname',
            username => 'username',
            password => 'password',

    ## Set up the classes for your recipe and ingredient objects.
    package Recipe;
    use base qw( Data::ObjectDriver::BaseObject );
        columns     => [ 'recipe_id', 'title' ],
        datasource  => 'recipe',
        primary_key => 'recipe_id',
        driver      => FoodDriver->driver,

    package Ingredient;
    use base qw( Data::ObjectDriver::BaseObject );
        columns     => [ 'ingredient_id', 'recipe_id', 'name', 'quantity' ],
        datasource  => 'ingredient',
        primary_key => [ 'recipe_id', 'ingredient_id' ],
        driver      => FoodDriver->driver,

    ## And now, use them!
    my $recipe = Recipe->new;
    $recipe->title('Banana Milkshake');

    my $ingredient = Ingredient->new;

    ## Needs more bananas!

    ## Shorthand constructor
    my $ingredient = Ingredient->new(recipe_id=> $recipe->id,
                                     name => 'Milk',
                                     quantity => 2);


Data::ObjectDriver is an object relational mapper, meaning that it maps object-oriented design concepts onto a relational database.

It's inspired by, and descended from, the MT::ObjectDriver classes in Six Apart's Movable Type and TypePad weblogging products. But it adds in caching and partitioning layers, allowing you to spread data across multiple physical databases, without your application code needing to know where the data is stored.


Data::ObjectDriver provides you with a framework for building database-backed applications. It provides built-in support for object caching and database partitioning, and uses a layered approach to allow building very sophisticated database interfaces without a lot of code.

You can build a driver that uses any number of caching layers, plus a partitioning layer, then a final layer that actually knows how to load data from a backend datastore.

For example, the following code:

    my $driver = Data::ObjectDriver::Driver::Cache::Memcached->new(
            cache    => Cache::Memcached->new(
                            servers => [ '' ],
            fallback => Data::ObjectDriver::Driver::Partition->new(
                            get_driver => \&get_driver,

creates a new driver that supports both caching (using memcached) and partitioning.

It's useful to demonstrate the flow of a sample request through this driver framework. The following code:

    my $ingredient = Ingredient->lookup([ $recipe->recipe_id, 1 ]);

would take the following path through the Data::ObjectDriver framework:

  1. The caching layer would look up the object with the given primary key in all of the specified memcached servers.

    If the object was found in the cache, it would be returned immediately.

    If the object was not found in the cache, the caching layer would fall back to the driver listed in the fallback setting: the partitioning layer.

  2. The partitioning layer does not know how to look up objects by itself--all it knows how to do is to give back a driver that does know how to look up objects in a backend datastore.

    In our example above, imagine that we're partitioning our ingredient data based on the recipe that the ingredient is found in. For example, all of the ingredients for a "Banana Milkshake" would be found in one partition; all of the ingredients for a "Chocolate Sundae" might be found in another partition.

    So the partitioning layer needs to tell us which partition to look in to load the ingredients for $recipe->recipe_id. If we store a partition_id column along with each $recipe object, that information can be loaded very easily, and the partitioning layer will then instantiate a DBI driver that knows how to load an ingredient from that recipe.

  3. Using the DBI driver that the partitioning layer created, Data::ObjectDriver can look up the ingredient with the specified primary key. It will return that key back up the chain, giving each layer a chance to do something with it.
  4. The caching layer, when it receives the object loaded in Step 3, will store the object in memcached.
  5. The object will be passed back to the caller. Subsequent lookups of that same object will come from the cache.


Data::ObjectDriver differs from other similar frameworks (e.g. Class::DBI) in a couple of ways:



Looks up/retrieves a single object with the primary key $id, and returns the object.

$id can be either a scalar or a reference to an array, in the case of a class with a multiple column primary key.


Looks up/retrieves multiple objects with the IDs \@ids, which should be a reference to an array of IDs. As in the case of lookup, an ID can be either a scalar or a reference to an array.

Returns a reference to an array of objects in the same order as the IDs you passed in. Any objects that could not successfully be loaded will be represented in that array as an undef element.

So, for example, if you wanted to load 2 objects with the primary keys [ 5, 3 ] and [ 4, 2 ], you'd call lookup_multi like this:

        [ 5, 3 ],
        [ 4, 2 ],

And if the first object in that list could not be loaded successfully, you'd get back a reference to an array like this:


where $object is an instance of Class.

Class->search(\%terms [, \%options ])

Searches for objects matching the terms %terms. In list context, returns an array of matching objects; in scalar context, returns a reference to a subroutine that acts as an iterator object, like so:

    my $iter = Ingredient->search({ recipe_id => 5 });
    while (my $ingredient = $iter->()) {

$iter is blessed in Data::ObjectDriver::Iterator package, so the above could also be written:

    my $iter = Ingredient->search({ recipe_id => 5 });
    while (my $ingredient = $iter->next()) {

The keys in %terms should be column names for the database table modeled by Class (and the values should be the desired values for those columns).

%options can contain:

Class->search(\@terms [, \%options ])

This is an alternative calling signature for the search method documented above. When providing an array of terms, it allows for constructing complex expressions that mix 'and' and 'or' clauses. For example:

    my $iter = Ingredient->search([ { recipe_id => 5 },
        -or => { calories => { value => 300, op => '<' } } ]);
    while (my $ingredient = $iter->()) {

Supported logic operators are: '-and', '-or', '-and_not', '-or_not'.

Class->add_trigger($trigger, \&callback)

Adds a trigger to all objects of class Class, such that when the event $trigger occurs to any of the objects, subroutine &callback is run. Note that triggers will not occur for instances of subclasses of Class, only of Class itself. See TRIGGERS for the available triggers.

Class->call_trigger($trigger, [@callback_params])

Invokes the triggers watching class Class. The parameters to send to the callbacks (in addition to Class) are specified in @callback_params. See TRIGGERS for the available triggers.


Saves the object $obj to the database.

If the object is not yet in the database, save will automatically generate a primary key and insert the record into the database table. Otherwise, it will update the existing record.

If an error occurs, save will croak.

Internally, save calls update for records that already exist in the database, and insert for those that don't.


Removes the object $obj from the database.

If an error occurs, remove will croak.

Class->remove(\%terms, \%args)

Removes objects found with the %terms. So it's a shortcut of:

  my @obj = Class->search(\%terms, \%args);
  for my $obj (@obj) {

However, when you pass nofetch option set to %args, it won't create objects with search, but issues DELETE SQL directly to the database.

  ## issues "DELETE FROM tbl WHERE user_id = 2"
  Class->remove({ user_id => 2 }, { nofetch => 1 });

This might be much faster and useful for tables without Primary Key, but beware that in this case Triggers won't be fired because no objects are instanciated.

Class->bulk_insert([col1, col2], [[d1,d2], [d1,d2]]);

Bulk inserts data into the underlying table. The first argument is an array reference of columns names as specified in install_properties

$obj->add_trigger($trigger, \&callback)

Adds a trigger to the object $obj, such that when the event $trigger occurs to the object, subroutine &callback is run. See TRIGGERS for the available triggers. Triggers are invoked in the order in which they are added.

$obj->call_trigger($trigger, [@callback_params])

Invokes the triggers watching all objects of $obj's class and the object $obj specifically for trigger event $trigger. The additional parameters besides $obj, if any, are passed as @callback_params. See TRIGGERS for the available triggers.


Data::ObjectDriver provides a trigger mechanism by which callbacks can be called at certain points in the life cycle of an object. These can be set on a class as a whole or individual objects (see USAGE).

Triggers can be added and called for these events:


For performance tuning, you can turn on query profiling by setting $Data::ObjectDriver::PROFILE to a true value. Or, alternatively, you can set the DOD_PROFILE environment variable to a true value before starting your application.

To obtain the profile statistics, get the global Data::ObjectDriver::Profiler instance:

    my $profiler = Data::ObjectDriver->profiler;

Then see the documentation for Data::ObjectDriver::Profiler to see the methods on that class.

In some applications there are phases of execution in which no I/O operations should occur, but sometimes it's difficult to tell when, where, or if those I/O operations are happening. One approach to surfacing these situations is to set, either globally or locally, the $Data::ObjectDriver::RESTRICT_IO flag. If set, this will tell Data::ObjectDriver to die with some context rather than executing network calls for data.


Transactions are supported by Data::ObjectDriver's default drivers. So each Driver is capable to deal with transactional state independently. Additionally <Data::ObjectDriver::BaseObject> class know how to turn transactions switch on for all objects.

In the case of a global transaction all drivers used during this time are put in a transactional state until the end of the transaction.


    ## start a transaction

    $recipe = Recipe->new;

    my $ingredient = Ingredient->new;
    $ingredient->name("more layers");

    if ($you_are_sure) {
    else {
        ## erase all trace of the above

Driver implementation

Drivers have to implement the following methods:

Nested transactions

Are not supported and will result in warnings and the inner transactions to be ignored. Be sure to end each transaction and not to let et long running transaction open (i.e you should execute a rollback or commit for each open begin_work).

Transactions and DBI

In order to make transactions work properly you have to make sure that the $dbh for each DBI drivers are shared among drivers using the same database (basically dsn).

One way of doing that is to define a get_dbh() subref in each DBI driver to return the same dbh if the dsn and attributes of the connection are identical.

The other way is to use the new configuration flag on the DBI driver that has been added specifically for this purpose: reuse_dbh.

    ## example coming from the test suite
        columns => [ 'recipe_id', 'partition_id', 'title' ],
        datasource => 'recipes',
        primary_key => 'recipe_id',
        driver => Data::ObjectDriver::Driver::Cache::Cache->new(
            cache => Cache::Memory->new,
            fallback => Data::ObjectDriver::Driver::DBI->new(
                dsn      => 'dbi:SQLite:dbname=global.db',
                reuse_dbh => 1,  ## be sure that the corresponding dbh is shared


A Partitioned, Caching Driver

    package Ingredient;
    use strict;
    use base qw( Data::ObjectDriver::BaseObject );

    use Data::ObjectDriver::Driver::DBI;
    use Data::ObjectDriver::Driver::Partition;
    use Data::ObjectDriver::Driver::Cache::Cache;
    use Cache::Memory;
    use Carp;

    our $IDs;

        columns     => [ 'ingredient_id', 'recipe_id', 'name', 'quantity', ],
        datasource  => 'ingredients',
        primary_key => [ 'recipe_id', 'ingredient_id' ],
        driver      =>
                cache    => Cache::Memory->new( namespace => __PACKAGE__ ),
                fallback =>
                        get_driver   => \&get_driver,
                        pk_generator => \&generate_pk,

    sub get_driver {
        my($terms) = @_;
        my $recipe;
        if (ref $terms eq 'HASH') {
            my $recipe_id = $terms->{recipe_id}
                or Carp::croak("recipe_id is required");
            $recipe = Recipe->lookup($recipe_id);
        } elsif (ref $terms eq 'ARRAY') {
            $recipe = Recipe->lookup($terms->[0]);
        Carp::croak("Unknown recipe") unless $recipe;
            dsn          => 'dbi:mysql:database=cluster' . $recipe->cluster_id,
            username     => 'foo',
            pk_generator => \&generate_pk,

    sub generate_pk {
        my($obj) = @_;



Data::ObjectDriver is very modular and it's not very diffucult to add new drivers.


Data::ObjectDriver is free software; you may redistribute it and/or modify it under the same terms as Perl itself.


Data::ObjectDriver developers can be reached via the following group:

Bugs should be reported using the CPAN RT system, patches are encouraged when reporting bugs.


Except where otherwise noted, Data::ObjectDriver is Copyright 2005-2006 Six Apart, All rights reserved.

syntax highlighting: