Re: RC2 (was: Announce: DBI 1.38 release candidate)

2003-08-29 Thread Tim Bunce 
On Thu, Aug 28, 2003 at 05:29:06PM -0400, Steven N. Hirsch wrote:
 On Thu, 28 Aug 2003, Tim Bunce wrote:
 
  On Thu, Aug 28, 2003 at 09:50:21AM -0400, Steven N. Hirsch wrote:
   
   Tim,
   
   I plan to beat on this over the next few days.  However, here are two 
   small changes which I've found to be necessary when working with a DB2 
   backend database.  Since making these mods all ugly messages are a thing 
   of the past.
   
   In my opinion, it's time to throw in the towel and report the true 
   'Active' status back to the proxy client with every call.
  
  I'd *really* like to know under what circumstances the Active status
  gets out of sync.
 
 It seems related to stored procedure calls, IIRC.  I fought with this 
 several months ago and ended up with the hacks below.  My problems are 
 very likely due to inconsistancies between DB2 CLI behavior and what one 
 would think was the obvious g.

Very likely :) But until we know what I'd still be tempted to say that
the problem lies with DBD::DB2 more than DBD::Proxy.

   I'm getting 
   hammered at work, but will attempt to code this up Real Soon Now g.
  
  Any patch to report the server-side active status needs to a) gracefully
  handle client-server version mismatches, and b) ideally implement a more
  flexible protocol in general so that new features can be added and version
  mismatches more gracefully handled in future.
 
 I agree 100%.  The existing communications protocol is a fragile, 
 hard-to-maintain mess.  This is why I've been putting off a permanent fix.  
 
 Do you agree that the move to something more elegant should involve a 
 different set of method names?

For the rpc logic, yes. Seems like the best way to make a fresh start.

 That's the only way to avoid breaking 
 older code (unless I'm missing the obvious).

Tim.

Re: RC2 (was: Announce: DBI 1.38 release candidate)

2003-08-28 Thread Steven N. Hirsch 
On Thu, 21 Aug 2003, Tim Bunce wrote:

 On Wed, Aug 20, 2003 at 03:49:18PM +0100, Tim Bunce wrote:
  I'd be grateful if you could take a moment to try out this
  release candidate of DBI 1.38:
 
 Thanks for all the feedback. Here's another. I've changed a few
 small things including enabling better testing of Driver.xst.
 I'm doing another release candidate because I suspect that might
 generate some compiler warings on some platforms.
 
 Same routine...
 
   http://homepage.eircom.net/~timbunce/DBI-1.38-rc2-20030821.tar.gz

Tim,

I plan to beat on this over the next few days.  However, here are two 
small changes which I've found to be necessary when working with a DB2 
backend database.  Since making these mods all ugly messages are a thing 
of the past.

In my opinion, it's time to throw in the towel and report the true 
'Active' status back to the proxy client with every call.  I'm getting 
hammered at work, but will attempt to code this up Real Soon Now g.

Steve


--- DBI-1.38/lib/DBD/Proxy.pm.orig  Tue Aug 19 20:15:28 2003
+++ DBI-1.38/lib/DBD/Proxy.pm   Thu Aug 28 09:44:22 2003
@@ -352,8 +352,10 @@
   $sth-{'proxy_sth'} = $rsth;
   # If statement is a positioned update we do not want any readahead.
   $sth-{'RowCacheSize'} = 1 if $stmt =~ /\bfor\s+update\b/i;
-# Since resources are used by prepared remote handle, mark us active.
-$sth-SUPER::STORE(Active = 1);
+  # In a perfect world, this would be correct.  However, until a clean
+  # universal solution is implemented for keeping the client in sync
+  # with the backend database, refrain from making a leap of faith.
+  # $sth-SUPER::STORE(Active = 1);
 }
 $sth;
 }
@@ -577,7 +579,9 @@
 
 sub finish ($) {
 my($sth) = @_;
-return 1 unless $sth-SUPER::FETCH('Active');
+# For reasons remarked upon in disconnect() above, let the
+# user decide when to hit the wire.
+# return 1 unless $sth-SUPER::FETCH('Active');
 my $rsth = $sth-{'proxy_sth'};
 $sth-SUPER::STORE('Active' = 0);
 return 0 unless $rsth; # Something's out of sync


-- 

Steven N. Hirsch   tie-line: 446-6557 ext: 802-769-6557

Staff Engineer Methodology Integration Team
ASIC Product Development   IBM Microelectronics

Re: RC2 (was: Announce: DBI 1.38 release candidate)

2003-08-28 Thread Tim Bunce 
On Thu, Aug 28, 2003 at 09:50:21AM -0400, Steven N. Hirsch wrote:
 
 Tim,
 
 I plan to beat on this over the next few days.  However, here are two 
 small changes which I've found to be necessary when working with a DB2 
 backend database.  Since making these mods all ugly messages are a thing 
 of the past.
 
 In my opinion, it's time to throw in the towel and report the true 
 'Active' status back to the proxy client with every call.

I'd *really* like to know under what circumstances the Active status
gets out of sync.

 I'm getting 
 hammered at work, but will attempt to code this up Real Soon Now g.

Any patch to report the server-side active status needs to a) gracefully
handle client-server version mismatches, and b) ideally implement a more
flexible protocol in general so that new features can be added and version
mismatches more gracefully handled in future.

Tim.

 Steve
 
 
 --- DBI-1.38/lib/DBD/Proxy.pm.origTue Aug 19 20:15:28 2003
 +++ DBI-1.38/lib/DBD/Proxy.pm Thu Aug 28 09:44:22 2003
 @@ -352,8 +352,10 @@
$sth-{'proxy_sth'} = $rsth;
# If statement is a positioned update we do not want any readahead.
$sth-{'RowCacheSize'} = 1 if $stmt =~ /\bfor\s+update\b/i;
 -# Since resources are used by prepared remote handle, mark us active.
 -$sth-SUPER::STORE(Active = 1);
 +  # In a perfect world, this would be correct.  However, until a clean
 +  # universal solution is implemented for keeping the client in sync
 +  # with the backend database, refrain from making a leap of faith.
 +  # $sth-SUPER::STORE(Active = 1);
  }
  $sth;
  }
 @@ -577,7 +579,9 @@
  
  sub finish ($) {
  my($sth) = @_;
 -return 1 unless $sth-SUPER::FETCH('Active');
 +# For reasons remarked upon in disconnect() above, let the
 +# user decide when to hit the wire.
 +# return 1 unless $sth-SUPER::FETCH('Active');
  my $rsth = $sth-{'proxy_sth'};
  $sth-SUPER::STORE('Active' = 0);
  return 0 unless $rsth; # Something's out of sync
 
 
 -- 
 
 Steven N. Hirsch   tie-line: 446-6557 ext: 802-769-6557
 
 Staff Engineer Methodology Integration Team
 ASIC Product Development   IBM Microelectronics

Re: RC2 (was: Announce: DBI 1.38 release candidate)

2003-08-28 Thread Steven N. Hirsch 
On Thu, 28 Aug 2003, Tim Bunce wrote:

 On Thu, Aug 28, 2003 at 09:50:21AM -0400, Steven N. Hirsch wrote:
  
  Tim,
  
  I plan to beat on this over the next few days.  However, here are two 
  small changes which I've found to be necessary when working with a DB2 
  backend database.  Since making these mods all ugly messages are a thing 
  of the past.
  
  In my opinion, it's time to throw in the towel and report the true 
  'Active' status back to the proxy client with every call.
 
 I'd *really* like to know under what circumstances the Active status
 gets out of sync.

It seems related to stored procedure calls, IIRC.  I fought with this 
several months ago and ended up with the hacks below.  My problems are 
very likely due to inconsistancies between DB2 CLI behavior and what one 
would think was the obvious g.

 
  I'm getting 
  hammered at work, but will attempt to code this up Real Soon Now g.
 
 Any patch to report the server-side active status needs to a) gracefully
 handle client-server version mismatches, and b) ideally implement a more
 flexible protocol in general so that new features can be added and version
 mismatches more gracefully handled in future.

I agree 100%.  The existing communications protocol is a fragile, 
hard-to-maintain mess.  This is why I've been putting off a permanent fix.  

Do you agree that the move to something more elegant should involve a 
different set of method names?  That's the only way to avoid breaking 
older code (unless I'm missing the obvious).

Steve

 
 Tim.
 
  Steve
  
  
  --- DBI-1.38/lib/DBD/Proxy.pm.orig  Tue Aug 19 20:15:28 2003
  +++ DBI-1.38/lib/DBD/Proxy.pm   Thu Aug 28 09:44:22 2003
  @@ -352,8 +352,10 @@
 $sth-{'proxy_sth'} = $rsth;
 # If statement is a positioned update we do not want any readahead.
 $sth-{'RowCacheSize'} = 1 if $stmt =~ /\bfor\s+update\b/i;
  -# Since resources are used by prepared remote handle, mark us active.
  -$sth-SUPER::STORE(Active = 1);
  +  # In a perfect world, this would be correct.  However, until a clean
  +  # universal solution is implemented for keeping the client in sync
  +  # with the backend database, refrain from making a leap of faith.
  +  # $sth-SUPER::STORE(Active = 1);
   }
   $sth;
   }
  @@ -577,7 +579,9 @@
   
   sub finish ($) {
   my($sth) = @_;
  -return 1 unless $sth-SUPER::FETCH('Active');
  +# For reasons remarked upon in disconnect() above, let the
  +# user decide when to hit the wire.
  +# return 1 unless $sth-SUPER::FETCH('Active');
   my $rsth = $sth-{'proxy_sth'};
   $sth-SUPER::STORE('Active' = 0);
   return 0 unless $rsth; # Something's out of sync
  
  
  -- 
  
  Steven N. Hirsch   tie-line: 446-6557 ext: 802-769-6557
  
  Staff Engineer Methodology Integration Team
  ASIC Product Development   IBM Microelectronics
  
  
 

-- 

Steven N. Hirsch   tie-line: 446-6557 ext: 802-769-6557

Staff Engineer Methodology Integration Team
ASIC Product Development   IBM Microelectronics

Re: RC2 (was: Announce: DBI 1.38 release candidate)

2003-08-22 Thread Steffen Goeldner 
All tests successful, 9 tests skipped.
Files=34, Tests=1215, 160 wallclock secs ( 0.00 cusr +  0.00 csys =  0.00 CPU)

perl -Mblib -MDBI -e DBI-installed_versions
Using C:/temp/DBI-1.38-RC2/blib
  Perl: 5.006001(MSWin32-x86-multi-thread)
  OS  : MSWin32 (4.0)
  DBI : 1.38
  DBD::Sponge : 11.09
  DBD::Proxy  : install_driver(Proxy) failed: Can't locate RPC/PlClient.pm in @INC
  DBD::Oracle : 1.14
  DBD::ODBC   : 1.05
  DBD::Multiplex  : 0.2
  DBD::ExampleP   : 11.10
  DBD::ADO: 2.6

But:

perl -Mblib -MDBI -e print for DBI-data_sources('ODBC')
Using C:/temp/DBI-1.38-RC2/blib
Usage: DBD::ODBC::dr::data_sources(drh, attr = NULL) at 
C:/temp/DBI-1.38-RC2/blib/lib/DBI.pm line 966.

Trace attached.


SteffenUsing C:/temp/DBI-1.38-RC2/blib
DBI 1.38-ithread dispatch trace level set to 9
Note: perl is running without the recommended perl -w option
- DBI-install_driver(ODBC) for MSWin32 perl=5.006001 pid=63 ruid=0 euid=0
   install_driver: DBD::ODBC version 1.05 loaded from 
C:/opt/perl/site/lib/DBD/ODBC.pm
New DBI::dr (for DBD::ODBC::dr, parent=, id=)
dbih_setup_handle(DBI::dr=HASH(0x15e9b58)=DBI::dr=HASH(0x183f680), DBD::ODBC::dr, 
0, Null!)
dbih_make_com(Null!, , DBD::ODBC::dr, 92, ) thr#015EEF8C
dbih_setup_attrib(DBI::dr=HASH(0x183f680), Err, Null!) SCALAR(0x15e39f8) (already 
defined)
dbih_setup_attrib(DBI::dr=HASH(0x183f680), State, Null!) SCALAR(0x15e3a88) 
(already defined)
dbih_setup_attrib(DBI::dr=HASH(0x183f680), Errstr, Null!) SCALAR(0x15e3a40) 
(already defined)
dbih_setup_attrib(DBI::dr=HASH(0x183f680), TraceLevel, Null!) 0 (already defined)
dbih_setup_attrib(DBI::dr=HASH(0x183f680), FetchHashKeyName, Null!) 'NAME' 
(already defined)
- install_driver= DBI::dr=HASH(0x15e9b58)
 data_sources DISPATCH (DBI::dr=HASH(0x15e9b58) rc1/3 @3 g1 ima801 pid#63) at 
C:/temp/DBI-1.38-RC2/blib/lib/DBI.pm line 966 via -e line 1
- data_sources for DBD::ODBC::dr (DBI::dr=HASH(0x15e9b58)~0x183f680 undef undef) 
thr#015EEF8C
Usage: DBD::ODBC::dr::data_sources(drh, attr = NULL) at 
C:/temp/DBI-1.38-RC2/blib/lib/DBI.pm line 966.
-- DBI::END
 disconnect_all DISPATCH (DBI::dr=HASH(0x15e9b58) rc1/3 @1 g0 ima801 pid#63) at 
C:/temp/DBI-1.38-RC2/blib/lib/DBI.pm line 652 via -e line 0
- disconnect_all for DBD::ODBC::dr (DBI::dr=HASH(0x15e9b58)~0x183f680) 
thr#015EEF8C
- disconnect_all= '' at C:/temp/DBI-1.38-RC2/blib/lib/DBI.pm line 652 via -e line 0
!DESTROY DISPATCH (DBI::dr=HASH(0x183f680) rc1/1 @1 g0 ima4 pid#63) during 
global destruction
!   - DESTROY for DBD::ODBC::dr (DBI::dr=HASH(0x183f680)~INNER) thr#015EEF8C
!   - DESTROY= (not implemented) during global destruction
DESTROY (dbih_clearcom) (drh 0x15e9b58 0x1863668, com 0x1862e58, imp 
DBD::ODBC::dr):
   FLAGS 0x215: COMSET Active Warn AutoCommit 
   PARENT undef
   KIDS 0 (0 Active)
   IMP_DATA undef
dbih_clearcom 0x15e9b58 (com 0x1862e58, type 1) done.

!DESTROY DISPATCH (DBI::dr=HASH(0x15e9b58) rc1/1 @1 g0 ima4 pid#63) during 
global destruction
!DESTROY for DBI::dr=HASH(0x15e9b58) ignored (inner handle gone)

Re: RC2 (was: Announce: DBI 1.38 release candidate)

2003-08-22 Thread Tim Bunce 
On Fri, Aug 22, 2003 at 10:10:52AM +0200, Steffen Goeldner wrote:
 perl -Mblib -MDBI -e print for DBI-data_sources('ODBC')
 Using C:/temp/DBI-1.38-RC2/blib
 Usage: DBD::ODBC::dr::data_sources(drh, attr = NULL) at 
 C:/temp/DBI-1.38-RC2/blib/lib/DBI.pm line 966.

Groan. I was in two minds about how to support using $dbh for
data_sources and I think the one I settled on wasn't the best.

So now, for RC3, I've gone back to Plan-A and added a $dbh-data_sources
method with a default implementation that does $dbh-{Driver}-data_sources.

Thanks.

Tim.

RE: RC2 (was: Announce: DBI 1.38 release candidate)

2003-08-22 Thread shildreth 
scotthperl -Mblib -MDBI -e 'DBI-installed_versions'
  Perl: 5.008001(i386-freebsd)
  OS  : freebsd (4.7-release-p3)
  DBI : 1.38
  DBD::mysql  : 2.9002
  DBD::XBase  : 0.210
  DBD::Sponge : 11.09
  DBD::SQLite : 0.25
  DBD::Proxy  : 0.2004
  DBD::Oracle : 1.14
  DBD::Multiplex  : 0.9
  DBD::File   : 0.2001
  DBD::ExampleP   : 11.10
  DBD::CSV: 0.2002
  DBD::AnyData: 0.05



On 21-Aug-2003 Tim Bunce wrote:
 On Wed, Aug 20, 2003 at 03:49:18PM +0100, Tim Bunce wrote:
 I'd be grateful if you could take a moment to try out this
 release candidate of DBI 1.38:
 
 Thanks for all the feedback. Here's another. I've changed a few
 small things including enabling better testing of Driver.xst.
 I'm doing another release candidate because I suspect that might
 generate some compiler warings on some platforms.
 
 Same routine...
 
   http://homepage.eircom.net/~timbunce/DBI-1.38-rc2-20030821.tar.gz
 
 Thanks.
 
 Tim.

--
E-Mail: [EMAIL PROTECTED]
Date: 22-Aug-2003
Time: 08:30:02
--

Re: RC2 (was: Announce: DBI 1.38 release candidate)

2003-08-22 Thread John . Tobey 

Using Sun cc:
All tests successful, 9 tests skipped.

  Perl: 5.006001(sun4-solaris)
  OS  : solaris (2.7)
  DBI : 1.38
  DBD::Sybase : 0.94
  DBD::Sponge : 11.09
  DBD::Proxy  : install_driver(Proxy) failed: Can't locate
RPC/PlClient.pm in @INC
  DBD::Oracle : 1.14
  DBD::Multiplex  : 0.2
  DBD::ExampleP   : 11.10
  DBD::ADO: install_driver(ADO) failed: Can't locate
Win32/OLE/Variant.pm in @INC

Using GCC:
dbipport.h: At top level:
dbipport.h:529: warning: `my_sv_2pvbyte' defined but not used
...Perl___notused warnings...

All tests successful, 9 tests skipped.

Using /gdbhome/tobey/build/DBI-1.38/blib
  Perl: 5.006001(sun4-solaris)
  OS  : solaris (2.7)
  DBI : 1.38
  DBD::Sybase : 0.93
  DBD::Sponge : 11.09
  DBD::Proxy  : install_driver(Proxy) failed: Can't locate
RPC/PlClient.pm in @INC
  DBD::Oracle : 1.03
  DBD::Multiplex  : 0.2
  DBD::ExampleP   : 11.10
  DBD::ADO: 1.17

RC2 (was: Announce: DBI 1.38 release candidate)

2003-08-21 Thread Tim Bunce 
On Wed, Aug 20, 2003 at 03:49:18PM +0100, Tim Bunce wrote:
 I'd be grateful if you could take a moment to try out this
 release candidate of DBI 1.38:

Thanks for all the feedback. Here's another. I've changed a few
small things including enabling better testing of Driver.xst.
I'm doing another release candidate because I suspect that might
generate some compiler warings on some platforms.

Same routine...

  http://homepage.eircom.net/~timbunce/DBI-1.38-rc2-20030821.tar.gz

Thanks.

Tim.