NAME¶
PGObject - A toolkit integrating intelligent PostgreSQL dbs into Perl objects
VERSION¶
Version 1.402.6
SYNPOSIS¶
To use without caching:
use PGObject;
To use with caching:
use PGObject ':cache';
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',
funcprefix => 'test__',
objtype => 'invoice',
objschema => 'public',
);
To call a function with enumerated arguments
my @results = PGObject->call_procedure(
dbh => $dbh,
funcname => $funcname,
funcprefix => 'test__',
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¶
clear_info_cache¶
This function clears the info cache if this was loaded with caching enabled.
The cache is also automatically cleared when a function that was run could not
be found (this could be caused by updating the db).
function_info(%args)¶
Arguments:
- dbh (required)
- Database handle
- funcname (required)
- function name
- funcschema (optional, default 'public')
- function schema
- funcprefix (optiona, default '')
- Prefix for the function. This can be useful for separating functions by
class.
- 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
- funcprefix (optiona, default '')
- Prefix for the function. This can be useful for separating functions by
class.
- 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.
- registry
- This is the name of the registry used for type conversion. It can be
omitted and defaults to 'default.' Note that use of a non-standard
registry currently does *not* merge changes from the default registry, so
you need to reregister types in non-default registries when you create
them.
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.
process_type($val, $type, $registry)¶
If $type is registered, returns "$type"->from_db($val). Otherwise
returns $val. If $val is an arrayref, loops through it for every item and
strips trialing [] from $type.
This module should generally only be used by type handlers or by this module.
new_registry($registry_name)¶
Creates a new registry if it does not exist. This is useful when segments of an
application must override existing type mappings.
Returns 1 on creation, 2 if already exists.
register_type(pgtype => $tname, registry => $regname, perl_class => $pm)¶
Registers a type as a class. This means that when an attribute of type $pg_type
is returned, that PGObject will automatically return whatever
$perl_class->from_db returns. This allows you to have a db-specific
constructor for such types.
The registry argument is optional and defaults to 'default'
If the registry does not exist, an error is raised. if the pg_type is already
registered to a different type, this returns 0. Returns 1 on success.
get_registered(registry => $registry, pg_type => $pg_type)¶
This is a public interface to the registry, which can be useful for composite
types decoding themselves from tuple data, and so forth.
unregister_type(pgtype => $tname, registry => $regname)¶
Tries to unregister the type. If the type does not exist, returns 0, otherwise
returns 1. This is mostly useful for when a specific type must make sure it
has the slot. This is rarely desirable. It is usually better to use a
subregistry instead.
$hashref = get_type_registry()¶
Returns the type registry. Mostly useful for debugging.
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() or a
to_db()
method, 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
REQUIRED INTERFACES¶
Registered types MUST implement a $class->from_db function accepts the string
from the database as its only argument, and returns the object of the desired
type.
Any type MAY present an $object->
to_db() interface, requiring no
arguments, and returning a valid value. These can be hashrefs as specified
above, arrayrefs (converted to PostgreSQL arrays by DBD::Pg) or scalar text
values.
UNDERSTANDING THE REGISTRY SYSTEM¶
The registry system allows Perl classes to "claim" PostgreSQL types
within a certain domain. For example, if I want to ensure that all numeric
types are turned into Math::BigFloat objects, I can build a wrapper class with
appropriate interfaces, but PGObject won't know to convert numeric types to
this new class, so this is what registration is for.
By default, these mappings are fully global. Once a class claims a type, unless
another type goes through the trouble of unregisterign the first type and
making sure it gets the authoritative spot, all items of that type get turned
into the appropriate Perl object types. While this is sufficient for the vast
number of applications, however, there may be cases where names conflict
across schemas or the like. To address this application components may create
their own registries. Each registry is fully global, but application
components can specify non-standard registries when calling procedures, and
PGObject will use only those components registered on the non-standard
registry when checking rows before output.
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.
Safely Handling Memoization of Catalog Lookups¶
It is important to remember, when writing PGObject top half frameworks that the
catalog lookups may be memoized and may come back as a data structure. This
means that changes to the structures returned from
get_function_info()
in this module and similar functions in other catalog-bound modules may not be
safe to modify in arbitrary ways. Therefore we recommend that the return
values from catalog-lookup functions are treated as immutable.
Normalizing output is safe provided there are no conflicts between naming
conventions. This is usually true since different naming conventions would
interfere withmapping. However, there could be cases where it is not true, for
example, where two different mapping modules agree on a subset of
normalization conventions but differ on some details. The two might safely
handle the same conventions but normalize differently resulting in conflicts
of both were used.
A BRIEF GUIDE TO THE NAMESPACE LAYOUT¶
Most names underneath PGObject can be assumed to be top-half modules and modules
under those can be generally assumed to be variants on those. There are,
however, a few reserved names:
- ::Debug is reserved for debugging information. For example, functions
which retrieve sources of functions, or grab diagnostics, or the like would
go here.
- ::Test is reserved for test framework extensions applible only here
- ::Type is reserved for PG aware type classes.
- For example, one might have PGObject::Type::BigFloat for a Math::Bigfloat
wrapper, or PGObject::Type::DateTime for a DateTime wrapper.
- ::Util is reserved for utility functions and classes.
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:
- •
- RT: CPAN's request tracker (report bugs here)
<http://rt.cpan.org/NoAuth/Bugs.html?Dist=PGObject>
- •
- AnnoCPAN: Annotated CPAN documentation
<http://annocpan.org/dist/PGObject>
- •
- CPAN Ratings
<http://cpanratings.perl.org/d/PGObject>
- •
- Search CPAN
<http://search.cpan.org/dist/PGObject/>
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-2014 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.