sub quotestr { my( $dbh, $str ) = @_; $str = '' if ! defined $str; return $dbh->quote( $str ); }

Yes, I realize that you asked for $dbh->quotestr($str) and I gave you quotestr($dbh,$str), but surely you aren't restricted from doing the latter.

Yes, there actually are ways to monkeypatch extra methods into somebody else's class. But such really isn't a good idea. Though, DBI is such an all-singing/all-dancing thing, that it is extremely common for people to produce objects that delegate so that they can do the bazillions of things a DBI object is expected to do while also doing a bunch of their own custom things (often including customizations to the things DBI does).

Lots of different routes used for such interface compositions: defining a new class that inherits from DBI -- often several layers of such -- either somewhat sanely with an inside-out object or sometimes by just defining a new class name and new methods and using a re-bless()ed object; more sanely using an object that "has a" DBI attribute and delegates to it or even just provides an accessor so you do $db->dbi()->some_dbi_method_here(); etc.

"Wrapping" DBI-related objects is just so rampant, that I actually discourage wrapping DBI yourself. Combining multiple wrappings is often ugly (though not as ugly as trying to use two utility classes that each want to inherit from DBI). So by avoiding your own wrapping, you can avoid some ugliness when you eventually run across some existing module you want to use that insists on wrapping DBI objects. For more blather trying to convince you of this wisdom, you could search for dependency injection.

So, if you just have the one extra method you want so far, then you can write a procedural module that provides that. You can even have the module load DBI for you so you don't have to have extra 'use' lines:

use My::DBI qw< quotestr >; # Also does 'use DBI;' my $dbh = DBI->connect( ... ); my $data = $dbh->selectall_arrayref( sprintf $sql, map { quotestr($dbh,$_) } @params );

Don't let the rampant "use placeholders!" meme get to you too much. It seems that few people have noticed many of the bugs and problems that can come with placeholders and/or realize that the claimed performance benefits just don't really materialize or matter in a lot of situations. If you have some other scheme that ensures that $dbh->quote(...) always gets applied, that is what is important.

- tye        


In reply to Re: Inserting an empty string, not NULL, with $dbh->quote() (monkeypatching) by tye
in thread Inserting an empty string, not NULL, with $dbh->quote() by moggs

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post, it's "PerlMonks-approved HTML":



  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Titles consisting of a single word are discouraged, and in most cases are disallowed outright.
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, details, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, summary, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • You may need to use entities for some characters, as follows. (Exception: Within code tags, you can put the characters literally.)
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.