Re: Antwort: RFC: DBI::Prof
On Fri, Dec 01, 2000 at 02:37:47AM +0100, Stas Bekman wrote: It would be much easier for Tim to do it from the inside than any of us doing the overloading hacking, but that's up to Tim to decide when if ever this should go in :) Things are changing for the better workwise now and I hope to get back to regular DBI and DBD::Oracle (and Oracle::OCI) work early next year. Meanwhile, I'll happily guide someone who's willing and mostly able to create a patch for DBI internals. It's shouldn't be too hard. Tim. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Antwort: RFC: DBI::Prof
On Fri, 1 Dec 2000, Tim Bunce wrote: On Fri, Dec 01, 2000 at 02:37:47AM +0100, Stas Bekman wrote: It would be much easier for Tim to do it from the inside than any of us doing the overloading hacking, but that's up to Tim to decide when if ever this should go in :) Things are changing for the better workwise now and I hope to get back to regular DBI and DBD::Oracle (and Oracle::OCI) work early next year. You said that at TPC :-) -- Matt/ /||** Director and CTO ** //||** AxKit.com Ltd ** ** XML Application Serving ** // ||** http://axkit.org ** ** XSLT, XPathScript, XSP ** // \\| // ** Personal Web Site: http://sergeant.org/ ** \\// //\\ // \\ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Antwort: RFC: DBI::Prof
On Fri, Dec 01, 2000 at 09:48:34AM +, Matt Sergeant wrote: On Fri, 1 Dec 2000, Tim Bunce wrote: On Fri, Dec 01, 2000 at 02:37:47AM +0100, Stas Bekman wrote: It would be much easier for Tim to do it from the inside than any of us doing the overloading hacking, but that's up to Tim to decide when if ever this should go in :) Things are changing for the better workwise now and I hope to get back to regular DBI and DBD::Oracle (and Oracle::OCI) work early next year. You said that at TPC :-) Yeah, well... there are plans and there are plans :) I recently gave notice to the company that I've been Technical Director of for many years that I'll be leaving in March 2001. Such big changes of direction take time to work up to and work out smoothly. I am specifically rearranging things so I have time for DBI related work. Tim. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Antwort: RFC: DBI::Prof
Tim Bunce wrote: On Fri, Dec 01, 2000 at 09:48:34AM +, Matt Sergeant wrote: On Fri, 1 Dec 2000, Tim Bunce wrote: On Fri, Dec 01, 2000 at 02:37:47AM +0100, Stas Bekman wrote: It would be much easier for Tim to do it from the inside than any of us doing the overloading hacking, but that's up to Tim to decide when if ever this should go in :) Things are changing for the better workwise now and I hope to get back to regular DBI and DBD::Oracle (and Oracle::OCI) work early next year. You said that at TPC :-) Yeah, well... there are plans and there are plans :) I recently gave notice to the company that I've been Technical Director of for many years that I'll be leaving in March 2001. Such big changes of direction take time to work up to and work out smoothly. I am specifically rearranging things so I have time for DBI related work. Very interesting. Although a bit OT, but I am sure everyone is interested, what changes are you planning for DBI ? Greg Tim. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Antwort: RFC: DBI::Prof
On Fri, Dec 01, 2000 at 12:23:26PM +, Greg Cope wrote: Tim Bunce wrote: Although a bit OT, but I am sure everyone is interested, what changes are you planning for DBI ? There's a ToDo file in the dist. I've probably a few others rattling around in my head. Tim. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Antwort: RFC: DBI::Prof
Hi, I'm not quite sure, but I think the following would produce wrong results, wouldn't it? $sth1 = $dbh-prepare(...); $sth2 = $dbh-prepare(...); $sth1-execute(); $sth3 = $dbh-prepare(...); $sth2-execute(); $sth3-execute(); Michael Jacob Datum: 28.11.2000 21:12 An:mod_perl list [EMAIL PROTECTED] Betreff: RFC: DBI::Prof Nachrichtentext: I have a huge project with lots of tables, and the performance wasn't that well. So I've started to review the tables definitions and have found that some indices were missing. I was sick from doing the tracing of all possible SQL calls manually, so I wrote this simple profiler. Take a look and tell me if you think it worths releasing on CPAN... hmm, why mod_perl list... because it works under mod_perl :) In fact I didn't test it under non mod_perl but it should work as well :) Anyway, enjoy :) _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ Prof.pm - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Antwort: RFC: DBI::Prof
On Thu, 30 Nov 2000 [EMAIL PROTECTED] wrote: Hi, I'm not quite sure, but I think the following would produce wrong results, wouldn't it? $sth1 = $dbh-prepare(...); $sth2 = $dbh-prepare(...); $sth1-execute(); $sth3 = $dbh-prepare(...); $sth2-execute(); $sth3-execute(); That's correct. So it's kinda disqualifies my hack to be placed on CPAN. At this moment I don't have the tuits to make it a non-hack and work for everybody, so I'll just leave it as it is in mod-perl list archive. May be I'll put it into the guide... It would be much easier for Tim to do it from the inside than any of us doing the overloading hacking, but that's up to Tim to decide when if ever this should go in :) Michael Jacob Datum: 28.11.2000 21:12 An:mod_perl list [EMAIL PROTECTED] Betreff: RFC: DBI::Prof Nachrichtentext: I have a huge project with lots of tables, and the performance wasn't that well. So I've started to review the tables definitions and have found that some indices were missing. I was sick from doing the tracing of all possible SQL calls manually, so I wrote this simple profiler. Take a look and tell me if you think it worths releasing on CPAN... hmm, why mod_perl list... because it works under mod_perl :) In fact I didn't test it under non mod_perl but it should work as well :) Anyway, enjoy :) _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ _ Stas Bekman JAm_pH -- Just Another mod_perl Hacker http://stason.org/ mod_perl Guide http://perl.apache.org/guide mailto:[EMAIL PROTECTED] http://apachetoday.com http://jazzvalley.com http://singlesheaven.com http://perl.apache.org http://perlmonth.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
