/ 
PGObject-1.01
River stage two • 8 direct dependents • 11 total dependents
/ PGObject

NAME

PGObject - Base class for PG Object subclasses

VERSION

Version 1.0

SYNPOSIS

To get basic info from a function

my $f_info = PGObject->function_info(
    dbh        =>  $dbh,
    funcname   =>  $funcname,
    funcschema =>  'public',
);

To get info about a function, filtered by first argument type

my $f_info = PGObject->function_info(
    dbh        =>  $dbh,
    funcname   =>  $funcname,
    funcschema =>  'public',
    objtype    =>  'invoice',
    objschema  =>  'public',
);

To call a function with enumerated arguments

my @results = PGObject->call_procedure(
    dbh          =>  $dbh,
    funcname     => $funcname,
    funcschema   => $funcname,
    args         => [$arg1, $arg2, $arg3],
);

To do the same with a running total

my @results = PGObject->call_procedure(
    dbh           =>  $dbh,
    funcname      => $funcname,
    funcschema    => $funcname,
    args          => [$arg1, $arg2, $arg3],
    running_funcs => [{agg => 'sum(amount)', alias => 'running_total'}],
);

DESCRIPTION

PGObject contains the base routines for object management using discoverable stored procedures in PostgreSQL databases. This module contains only common functionality and support structures, and low-level API's. Most developers will want to use more functional modules which add to these functions.

The overall approach here is to provide the basics for a toolkit that other modules can extend. This is thus intended to be a component for building integration between PostgreSQL user defined functions and Perl objects.

Because decisions such as state handling are largely outside of the scope of this module, this module itself does not do any significant state handling. Database handles (using DBD::Pg 2.0 or later) must be passed in on every call. This decision was made in order to allow for diversity in this area, with the idea that wrapper classes would be written to implement this.

FUNCTIONS

function_info(%args)

Arguments:

dbh (required)

Database handle

funcname (required)

function name

funcschema (optional, default 'public')

function schema

argtype1 (optional)

Name of first argument type. If not provided, does not filter on this criteria.

argschema (optional)

Name of first argument type's schema. If not provided defaults to 'public'

This function looks up basic mapping information for a function. If more than one function is found, an exception is raised. This function is primarily intended to be used by packages which extend this one, in order to accomplish stored procedure to object mapping.

Return data is a hashref containing the following elements:

args

This is an arrayref of hashrefs, each of which contains 'name' and 'type'

name

The name of the function

num_args

The number of arguments

call_procedure(%args)

Arguments:

funcname

The function name

funcschema

The schema in which the function resides

args

This is an arrayref. Each item is either a literal value, an arrayref, or a hashref of extended information. In the hashref case, the type key specifies the string to use to cast the type in, and value is the value.

orderby

The list (arrayref) of columns on output for ordering.

running_funcs

An arrayref of running windowed aggregates. Each contains two keys, namely 'agg' for the aggregate and 'alias' for the function name.

These are aggregates, each one has appended 'OVER (ROWS UNBOUNDED PRECEDING)' to it.

Please note, these aggregates are not intended to be user-supplied. Please only allow whitelisted values here or construct in a tested framework elsewhere. Because of the syntax here, there is no sql injection prevention possible at the framework level for this parameter.

WRITING PGOBJECT-AWARE HELPER CLASSES

One of the powerful features of PGObject is the ability to declare methods in types which can be dynamically detected and used to serialize data for query purposes. Objects which contain a pgobject_to_db(), that method will be called and the return value used in place of the object. This can allow arbitrary types to serialize themselves in arbitrary ways.

For example a date object could be set up with such a method which would export a string in yyyy-mm-dd format. An object could look up its own definition and return something like :

{ cast => 'dbtypename', value => '("A","List","Of","Properties")'}

If a scalar is returned that is used as the serialized value. If a hashref is returned, it must follow the type format:

type  => variable binding type,
cast  => db cast type
value => literal representation of type, as intelligible by DBD::Pg

TODO FOR TYPE INTERFACE

The above interface will only be fully functional when a registration interface is provided. This is planned for 1.1. A registration interface would allow PGObject to create new objects based on database element return type. Until then this must be done on the application level.

WRITING TOP-HALF OBJECT FRAMEWORKS FOR PGOBJECT

PGObject is intended to be the database-facing side of a framework for objects. The intended structure is for three tiers of logic:

Database facing, low-level API's
Object management modules
Application handlers with things like database connection management.

By top half, we are referring to the second tier. The third tier exists in the client application.

The PGObject module provides only low-level API's in that first tier. The job of this module is to provide database function information to the upper level modules.

We do not supply type information, If your top-level module needs this, please check out https://code.google.com/p/typeutils/ which could then be used via our function mapping APIs here.

AUTHOR

Chris Travers, <chris.travers at gmail.com>

BUGS

Please report any bugs or feature requests to bug-pgobject at rt.cpan.org, or through the web interface at http://rt.cpan.org/NoAuth/ReportBug.html?Queue=PGObject. I will be notified, and then you'll automatically be notified of progress on your bug as I make changes.

SUPPORT

You can find documentation for this module with the perldoc command.

perldoc PGObject

You can also look for information at:

ACKNOWLEDGEMENTS

This code has been loosely based on code written for the LedgerSMB open source accounting and ERP project. While that software uses the GNU GPL v2 or later, this is my own reimplementation, based on my original contributions to that project alone, and it differs in signficant ways. This being said, without LedgerSMB, this module wouldn't exist, and without the lessons learned there, and the great people who have helped make this possible, this framework would not be half of what it is today.

SEE ALSO

PGObject::Simple - Simple mapping of object properties to stored proc args
PGObject::Simple::Role - Moose-enabled wrapper for PGObject::Simple

COPYRIGHT

COPYRIGHT (C) 2013 Chris Travers

Redistribution and use in source and compiled forms with or without modification, are permitted provided that the following conditions are met:

  • Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer as the first lines of this file unmodified.

  • Redistributions in compiled form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the source code, documentation, and/or other materials provided with the distribution.

THIS SOFTWARE IS PROVIDED BY THE AUTHOR(S) "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR(S) BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.