Re^2: A brief survey of the DBI usability layer modules on the CPAN

Well, that sentence was mostly a disclaimer, because sometimes you find these great modules that turn out to be not so great once you try them in anger. I haven’t had such problems with DBIx::Simple – it turned out to be just as nice to use as expected.

There is just one monkeypatch in my code that I’d like to see as part of the module itself:

sub DBIx::Simple::Result::hash_array { scalar shift->hashes( @_ ) }
[download]

This isn’t for any fault of DBIx::Simple’s, it’s just because of the fact that method calls in Template Toolkit are always in list context. DBIx::Class added a scalar-context-only variant of its search method called search_rs to deal with the same problem.

Makeshifts last the longest.

Comment on Re^2: A brief survey of the DBI usability layer modules on the CPAN Download Code

Replies are listed 'Best First'.
Re^3: A brief survey of the DBI usability layer modules on the CPAN by Juerd (Abbot) on Jun 22, 2007 at 11:07 UTC
I'm glad to hear you're still happy with DBIx::Simple. About the TT issue: While I understand the problem and acknowledge that it is annoying, I strongly believe that this should not be fixed in the numerous modules that happen to be compatible with Template Toolkit, but in Template Toolkit itself. I might release a compatibility package, but I'm not willing to mess with DBIx::Simple itself for this. I find the name "hash_array" very confusing, by the way. I'd probably call it "array_of_hashes". The correct solution to this problem, if you want it in DBIx::Simple, is to use your own result class. Untested code follows. use strict; package DBIx::Simple::TT; use base 'DBIx::Simple'; sub connect { my $self = shift->SUPER::connect(@_); $self->result_class = 'DBIx::Simple::Result::ForcedScalar'; } package DBIx::Simple::Result::ForcedScalar; use base 'DBIx::Simple::Result'; my $stash = \%DBIx::Simple::Result::ForcedScalar::; our %list_methods; $list_methods{$_} = 1 for qw( arrays hashes list flat columns map map_hashes map_arrays ); for my $method (keys %list_methods) { $method =~ /^[a-z]\w+$/ or next; my $supermethod = "SUPER::$method"; $stash->{$method} = sub { scalar shift->$method(@_) }; } [download] Do you think that this would solve your problem? Juerd # { site => 'juerd.nl', do_not_use => 'spamtrap', perl6_server => 'feather' }	[reply] [d/l]
Re^4: A brief survey of the DBI usability layer modules on the CPAN by Aristotle (Chancellor) on Jul 02, 2007 at 00:46 UTC
I strongly believe that this should not be fixed in the numerous modules that happen to be compatible with Template Toolkit, but in Template Toolkit itself. In theory you are right. In practice, TT3 is a longer time coming than Perl 6. Do you think that this would solve your problem? As written, your suggested solution requires a decision at DBIS handle construction time whether the resultset methods should be context-sensitive or scalar-context-only. That’s quite simply not possible for me: all of the database queries are in isolated in a class which creates a single DBIS handle at instatiation time. But make it `$stash->{ $method . '_ref' } = sub { scalar shift->$supermethod( @ +_ ) };` [download] and it’s all good. (Modulo naming scheme anyway.) (PS.: having `list` in the list of covered methods is pretty pointless.) Makeshifts last the longest.	[reply] [d/l] [select]


Keep It Simple, Stupid
	PerlMonks