Connected Callback Errors Ignored

[David E. Wheeler]

DBIers,

Given this script:

use v5.18;
use warnings;
use utf8;
use DBI;

my $dbh = DBI-connect('dbi:SQLite:', '', '', {
PrintError = 0,
RaiseError = 1,
AutoCommit = 1,
Callbacks = {
connected = sub {
say 'connected';
$_[0]-do('SELECT 1 from foo');
return;
},
}
});

say 'go';
$dbh-do('SELECT 1 from foo');

The output is:

connected
go
DBD::SQLite::db do failed: no such table: foo at /Users/david/bin/try line 
22.

That doesn't seem right to me. Shouldn't the connected callback throw an 
exception? IOW, I would not expect go to be output.

Best,

David

Re: AnyData open API

[Jens Rehsack]

Hi Jonathan,

Am 08.11.2013 um 02:59 schrieb djg...@gmail.com:

 I hope my reply comes across correctly.

Depends on your intension ;)
I’d say: yes.

 Hi Jens and Sven,
 
 I understand that AnyData needs a reset. What is consensus if direction? 
 
 For my project I need to manage a big variety of source formats, so I'll be 
 willing to participate in redesign or coding of AnyData if need be. 
 Otherwise 
 I'll have to dream up my own data format abstraction layer.
 
 There are generally four types of sources or formats in my environment
 
 Databases accessible through DBI
 Databases accessible through command line binaries
 Records based files, such as csv
 Table based files, such as /etc/hosts, json etc.
 
 Any lessons we can stage from Augeas and it's concept of lenses? Or just 
 bridge 
 between Augeas and DBI?
 
 
 I just started looking into AnyData since I didn’t like all the work I was 
 doing to use the template feature of unpack then while processing building a 
 SQLite in-memory/file DB. I am thinking DBD::AnyData would be better and 
 easier to maintain than what I have built 
 
 I notice DBD::AnyData doesn’t work with DBI  1.622. I am willing to help but 
 not sure where to start. I may try to build a proof of concept from an older 
 DBI to see if it will be any faster/easier to maintain that what I am doing 
 now.

I would recommend 1st to join IRC - at irc.perl.org in #dbi channel.
If this is an absolute no-go, maybe a Hangout on Google+ would work better?

However - the first step should be to read the concept and api of
DBI::DBD::SqlEngine::(Table|Data)Source. I would favor this API even for
AnyData and it’s storage backends.

Let’s together develop an API on-top of it for parsing, if necessary.

When AnyData got rid of the internal Tie stuff, a reintegration of
DBD::AnyData into DBD::File will be a smooth way.

Cheers
-- 
Jens Rehsack
rehs...@gmail.com