Tim Bunce [EMAIL PROTECTED] wrote: > On Mon, Jul 14, 2003 at 01:24:41PM -0400, Hardy Merrill wrote: > > Tim (or anyone else who knows), I'm wondering if you have > > plans to create a 2nd edition to 'Programming the Perl DBI'? > > It's been over 3 years since the 1st edition - I for one > > would like to see a 2nd edition. > > Synchronisity is a funny thing... I signed the contract for the > 2nd edition today. > > Jeff Zucker, of DBD::AnyData and SQL::Statement fame, will be > co-authoring this edition with me. > > Maybe, just maybe, it'll be available by next OSCON...
Damb, we have to wait a whole year?? ;-) Just kidding - the fact that I'm anxious for the 2nd edition is a good thing. While we're on the subject, I'd like to put in a request for some in-depth discussion in the book about subclassing the DBI. I know the DBI perldocs does talk about it and give some examples, but I'd like to see *more* depth given to this topic. My thought would be something along the lines of Here's a typical example where I want to use DBI with MySQL, but I want to do it in such a way as to minimize the impact if someday I want to change the database to PostgreSQL or Oracle. And, here's one example of how you can do that, or make that easier, by subclassing the DBI. The DBI perldocs now talk about the mechanics of how to subclass the DBI, and the example is ok, but if I don't have a need to alter the behavior of prepare or fetch or any other DBI method, then I don't understand how subclassing the DBI is useful to me. Or maybe I just don't understand it well enough to know why it would be useful to alter the behavior of the DBI methods. For years I have happily used the "stock" DBI methods with no apparent need to change the behavior of those methods. But if I can see a real world practical example of how subclassing the DBI can help me, I might finally get it, and start subclassing the DBI myself. I have this feeling that being able to subclass the DBI is a great tool, but I don't quite understand it well enough yet - help me with a good practical example or two. Thanks. -- Hardy Merrill Red Hat, Inc.
