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

[Chris Travers <..hidden..>]

On Fri, Jan 22, 2016 at 7:05 PM, Chris Bennett
<..hidden..> wrote:
> 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?

Ok, here is the design idea -- my recommendation is still a basic make test.

Tests that confirm that the module basiclly works should be run
without environment variables.

Tests that may require outside knowledge require environment variables.

Keep in mind we are dependent on client libraries, not on the server.
The module could be used with PostgreSQL on a different system
entirely.  If you insist on doing db testing, then your tests are
dependent on the server, not just on the client libraries.

So just a make test.  If someone wants more, this can be documented.
>
> Thanks,
> 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!
> http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
> _______________________________________________
> Ledger-smb-devel mailing list
> ..hidden..
> https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel

------------------------------------------------------------------------------
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!
http://pubads.g.doubleclick.net/gampad/clk?id=267308311&iu=/4140
_______________________________________________
Ledger-smb-devel mailing list
..hidden..
https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel