Re: Making DBI (results) more strict

2014-02-11 Thread Darren Duncan
Max, you can distinguish a missing column from a null one quite easily in 
regular Perl.  If "exists $hash->{key}" is false then the column doesn't exist, 
where if that is true but "defined $hash->{key}" is false then it exists but is 
null. -- Darren Duncan


On 2/10/2014, 10:57 AM, Max Maischein wrote:

Hi all,

I recently discovered the greatness that is Hash::Util::lock_ref_keys , when
used together with ->fetchall_arrayref() like this:

 ...
 my $rows= $sth->fetchall_arrayref( {} };
 for( @$rows ) {
 lock_ref_leys( $_ );
 };
 ...

This prevents me from accessing hash keys that don't exist. Usually, this is
inconvenient, but with SQL query results, I (too) often encounter different case
for the column names, or other inconsistencies. Especially when columns are
allowed to be NULL, it may take me a while to figure out that I'm looking at the
wrong key.

I'd like to enable this returning of locked hashes from within DBI, preferrably
on a per-$dbh-level:

 my $dbh= DBI->connect( $dsn, 'scott', 'tiger', { RaiseError => 1,
StrictResults => 1 });

Alternatively, I'm also open to suggestions on how to best implement this
feature in a separate module, tentatively named DBI::strict. I've thought about
doing some AUTOLOAD reflection onto the real $dbh, but I'm unsure about how to
best approach wrapping arbitrary DBD handles/statement handles with my
DBI::strict::st without interfering. Also, I'd appreciate hints on what
subroutine(s) would be the most appropriate to enable locking the hashes, as I
want to write as little new code for such a feature as necessary.

Thanks for reading,
-max





Re: Request consideration of DBD::Neo4p registration

2014-02-11 Thread demerphq
On 10 February 2014 09:59, Martin J. Evans  wrote:
> On 10/02/14 08:36, Tim Bunce wrote:
>>
>> On Mon, Feb 10, 2014 at 12:19:05AM -0500, Mark Jensen wrote:
>>>
>>> Greetings DBI, I would like to register DBD::Neo4p in DBI with prefix
>>> neo_. It provides a DBI wrapper
>>> for a REST interface to the Neo4j db.
>>
>>
>> Done.
>>
>>> https://metacpan.org/pod/REST::Neo4p
>>
>>
>> I'd suggest abstracting out the transport interface to allow multiple
>> transports. Similar to https://metacpan.org/pod/Elasticsearch::Transport
>
>
> ++
>
>
>> That lets you, and others, implement other transport/connection modules.
>> I mention this because LWP is not the fastest HTTP interface. There are
>> several transports for Elasticsearch that are significantly faster.
>> For example https://metacpan.org/pod/Elasticsearch::Cxn::NetCurl
>
>
> We found curl much faster than LWP - see
> http://www.martin-evans.me.uk/node/117 for some numbers and a problem I hit
> (and got around) with POSTing in Curl.

You might want to check out:

http://search.cpan.org/~avar/Hijk-0.12/lib/Hijk.pm

Very fast.

Yves


-- 
perl -Mre=debug -e "/just|another|perl|hacker/"


Re: Request consideration of DBD::Neo4p registration

2014-02-11 Thread Martin J. Evans

On 11/02/2014 17:56, demerphq wrote:

On 10 February 2014 09:59, Martin J. Evans  wrote:

On 10/02/14 08:36, Tim Bunce wrote:


On Mon, Feb 10, 2014 at 12:19:05AM -0500, Mark Jensen wrote:


 Greetings DBI, I would like to register DBD::Neo4p in DBI with prefix
neo_. It provides a DBI wrapper
 for a REST interface to the Neo4j db.



Done.


 https://metacpan.org/pod/REST::Neo4p



I'd suggest abstracting out the transport interface to allow multiple
transports. Similar to https://metacpan.org/pod/Elasticsearch::Transport



++



That lets you, and others, implement other transport/connection modules.
I mention this because LWP is not the fastest HTTP interface. There are
several transports for Elasticsearch that are significantly faster.
For example https://metacpan.org/pod/Elasticsearch::Cxn::NetCurl



We found curl much faster than LWP - see
http://www.martin-evans.me.uk/node/117 for some numbers and a problem I hit
(and got around) with POSTing in Curl.


You might want to check out:

http://search.cpan.org/~avar/Hijk-0.12/lib/Hijk.pm

Very fast.

Yves




Thanks Yves, I'll be sure to check that out. I need fast and features 
are less important to me.


Martin
--
Martin J. Evans
Wetherby, UK


[perl5-dbi/DBI-Test] 3c3bd2: Add notes about threads, subtests, and data record...

2014-02-11 Thread Tim Bunce
  Branch: refs/heads/master
  Home:   https://github.com/perl5-dbi/DBI-Test
  Commit: 3c3bd227b2ba375b83af3b0b6886003bca3c2f50
  
https://github.com/perl5-dbi/DBI-Test/commit/3c3bd227b2ba375b83af3b0b6886003bca3c2f50
  Author: Tim Bunce 
  Date:   2014-02-11 (Tue, 11 Feb 2014)

  Changed paths:
M sandbox/tim/README.pod

  Log Message:
  ---
  Add notes about threads, subtests, and data recording




Re: Request consideration of DBD::Neo4p registration

2014-02-11 Thread demerphq
On 11 February 2014 23:37, Martin J. Evans  wrote:
> On 11/02/2014 17:56, demerphq wrote:
>>
>> On 10 February 2014 09:59, Martin J. Evans  wrote:
>>>
>>> On 10/02/14 08:36, Tim Bunce wrote:


 On Mon, Feb 10, 2014 at 12:19:05AM -0500, Mark Jensen wrote:
>
>
>  Greetings DBI, I would like to register DBD::Neo4p in DBI with
> prefix
> neo_. It provides a DBI wrapper
>  for a REST interface to the Neo4j db.



 Done.

>  https://metacpan.org/pod/REST::Neo4p



 I'd suggest abstracting out the transport interface to allow multiple
 transports. Similar to https://metacpan.org/pod/Elasticsearch::Transport
>>>
>>>
>>>
>>> ++
>>>
>>>
 That lets you, and others, implement other transport/connection modules.
 I mention this because LWP is not the fastest HTTP interface. There are
 several transports for Elasticsearch that are significantly faster.
 For example https://metacpan.org/pod/Elasticsearch::Cxn::NetCurl
>>>
>>>
>>>
>>> We found curl much faster than LWP - see
>>> http://www.martin-evans.me.uk/node/117 for some numbers and a problem I
>>> hit
>>> (and got around) with POSTing in Curl.
>>
>>
>> You might want to check out:
>>
>> http://search.cpan.org/~avar/Hijk-0.12/lib/Hijk.pm
>>
>> Very fast.
>>
>> Yves
>>
>>
>
> Thanks Yves, I'll be sure to check that out. I need fast and features are
> less important to me.

FWIW, it was created by dev's working on Booking.com's internal
elastic search setup. It is designed to be as lightning fast for that
type of purpose as possible. We also use it for talking to other
services served via HTTP. The guys that work on it are really quite
brilliant.

cheers,
Yves


-- 
perl -Mre=debug -e "/just|another|perl|hacker/"