[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: RFC: Feedback on design of PGObject and what should be fixed in 2.0

On Thu, Jan 21, 2016 at 09:13:52AM +0100, Chris Travers wrote:
> Hi;
> Have any other developers worked with the PGObject framework here?
> Here are my thoughts regarding things which should probably be changed:
> 1.  I would like to avoid requirinng autocommit off for db handles and
> instead set it off for the series of calls.
> 2.  I would like to provide better exception handling when a query goes
> wrong.  In some cases (we couldn't find a function) we should still
> probably die, but when the function errors, we could use better error
> handlign rather than dying and expecting the using application to handle it.
> My thinking is (for 1.6) to correct the second by making exception handling
> configurable.  My thinking is to:
> 1)  Allow exceptions from functions to pass back an exception object on
> failure.
> 2)  Allow the class or call to accept an error handler.
> the default would probably still be the same.
> During the 1.5-1..6 period I would like to get these packages working on
> both Perl5 (CPAN) and Perl6.

I am working on bringing the PGObject modules into OpenBSD.

Working on PGObject, I find this in the testing:

plan skip_all => 'Not set up for db tests' unless $ENV{DB_TESTING};
# Initial setup
my $dbh1 = DBI->connect('dbi:Pg:', 'postgres') ;

plan skip_all => 'Needs superuser connection for this test script'
unless $dbh1;

How should I handle this? Just define ENV{DB_TESTING} to something?

Chris Bennett

Site24x7 APM Insight: Get Deep Visibility into Application Performance
APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month
Monitor end-to-end web transactions and take corrective actions now
Troubleshoot faster and improve end-user experience. Signup Now!
Ledger-smb-devel mailing list