/ 
Class-PObject-2.06_02
River stage zero No dependents
/ Class::PObject::Type

NAME

Class::PObject::Type - Column type specification

SYNOPSIS

pobject User => {
    columns => ['id', 'login', 'psswd', 'email', 'bio'],
    tmap    => {
        id      => 'INTEGER',
        login   => 'VARCHAR(18)',
        psswd   => 'ENCRYPT',
        email   => 'VARCHAR(40)',
        bio     => 'TEXT',
        key     => 'MD5'
    }
};

DESCRIPTION

Class::PObject allows you to specify types for values that each column will hold. There are several uses for this:

  1. Allows specific drivers to be able to optimize object storage as well as retrieval

  2. Allows to filter certain column values before being inserted. Good example would be, MD5 and ENCRYPT column types, where each value should be encrypted before being stored in the database. This encryption will also apply while loading objects

TYPE SPECIFICATION

The rest of this manual will talk about how column specification is designed. This information will be useful only if you want to be able to extend this type-mapping functionality.

Each column type is treated as the name of the class with the same specs as any other class created using pobject construct. Any attributes, if applicable, should be enclosed into parenthesis.

For example, types, VARCHAR(100), INTEGER, ENCRYPT, MD5 and TEXT are all valid column types.

Let's assume the following class declaration:

pobject Author => {
    columns => ['id', 'name'],
    tmap    => {
        name    => 'VARCHAR(32)'
    }
};

DEFAULT COLUMN TYPE

While declaring classes, we don't have to declare types of all columns. If we don't all the columns would default to VARCHAR(255), with the exception of id column, which defaults to INTEGER.

TYPE CLASS

We said each type was a class. This classes have the same interface as any other class generated through pobject construct. Instead of being generated out of Class::PObject::Template, however, these particular classes inherit from Class::PObject::Type.

HOW IT WORKS

So, how pobject will interpret our VARCHAR(32) anyway?

It assumes that there is a class called VARCHAR, and creates a new object of this class by calling its new() - constructor with the value passed to this column.

For example, if we were to do something like:

$author = new Author();
$author->name("Sherzod Ruzmetov");

When we called name(), that's what happens behind the scenes:

require VARCHAR;
$type = new VARCHAR(id=>"Sherzod Ruzmetov", args=>32);

And when we save the object into database, it would call its id() method and uses its return value to store into disk.

When the column is loaded, pobject will only load the strings as are, and will inflate the object only once needed.

So in other words, when we do:

$author = Author->load(217);

pobject first just loads the column values as are, and when we try to access the value of the column by saying:

$name = $author->name();

it will do something like:

require VARCHAR;
$type = VARCHAR->load("Sherzod Ruzmetov"); 
return $type

So, in other words, above name() method returns an object. However, this object in string context, will always return the value of its id thanks to operator overloading.

HAS-A RELATIONSHIPS

Because type classes provide the same interface as any other pobject class, we could define object relationships as easily as defining column types.

SEE ALSO

Class::PObject::Type::INTEGER, Class::PObject::Type::VARCHAR, Class::PObject::Type::ENCRYPT, Class::PObject::Type::MD5, Class::PObject::Type::SHA1

COPYRIGHT AND LICENSE

For author and copyright information refer to Class::PObject's online manual.