Re: Request consideration of DBD::Neo4p registration
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/"
[perl5-dbi/DBI-Test] 3c3bd2: Add notes about threads, subtests, and data record...
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
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
Re: Request consideration of DBD::Neo4p registration
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: Making DBI (results) more strict
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