No such thing as a small change | |
PerlMonks |
comment on |
( [id://3333]=superdoc: print w/replies, xml ) | Need Help?? |
If the subquery emulation has been deprecated, change the short tagline in the NAME section ("Easy-to-use...") to reflect only the primary purposes. You're right. It has already been removed, even :) I used to be proud of this feature, because it enabled users of MySQL to use subqueries and a lot of people seemed to really want that. But MySQL now supports that natively and thus of course in a much better way. And I don't want to maintain the ugly code needed for it just for database drivers that aren't used much anyway. The method named _die is confusing, since it doesn't have anything to do with the core die(); perhaps naming it something like done, finished, or destroy would make it clearer that this is a pre-destruction cleanup method Or during-destruction, or triggering-destruction. It's kind of hard to explain and at the time I really had trouble finding a good name. I still find that hard. Nothing describes it really well. I think _die is as bad a name as the other suggestions. For method names, I never really care about clashing with builtins. While I think the "keep_statements" functionality is nicely implemented, if its purpose is just for performance, might you be better off using the DBI's built-in prepare_cached instead? prepare_cached Is dangerous, as described in the documentation of DBI under the "Caveat Emptor" paragraph. Since DBI 1.40, there's a way to make it safe, but I use DBIx::Simple on boxes that have older versions of DBI. Its functionality is also driver dependent. Another thing is that DBI doesn't limit the number of cached handles, which can be a serious problem in persistent environments like mod_perl. Oh, and I need to control what happens to STHs because of the extensive error reporting. DBI could give the STH to something that isn't DBIx::Simple. (Which by the way is also a security implication, since you can use it without re-execute()ing. (Of course, nothing realli is safe in Perl, since even lexicals can be accessed from elsewhere...)) In addition to referring people to DBIx::Abstract, you might want to also mention SQL::Abstract, perhaps even with a short example showing how easy it is to use SQL::Abstract with your module. Good idea. Will do! (By the way - the link in your post is broken) Update: In fact, the more I think about it, SQL::Abstract is VERY compatible with DBIx::Simple: its return values can be used directly, without modification, with DBIx::Simple's query method. Although I don't like abstracting SQL (unless completely, that is: with Class::DBI), it's the most often requested feature. I could even wrap its four main methods entirely, as none of its methods clash with DBIx::Simple's methods. That would probably something like: (untested)
Is there any reason I should or should not do this? Another update: It's implemented in my local copy now, in an even simpler way. Just to make sure some things, I've emailed the author of SQL::Abstract with some questions, but I don't expect anything negative back. So probably DBIx::Simple 1.23 will have these four new methods. With regard to testing, I've struggled with the same issue; this kind of testing is trickier than for self-contained modules that don't have to talk to a database. My suggestion would be to use EU::MM's prompt() function to ask the user for a test DSN when Makefile.PL is run; note that EU::MM will skip this automatically when running from within CPAN. Someone else is working on the tests. I don't know what it'll look like :) Juerd # { site => 'juerd.nl', plp_site => 'plp.juerd.nl', do_not_use => 'spamtrap' } In reply to Re: Re: DBIx::Simple - Your opinions/review please
by Juerd
|
|