Subject: RE: Testing DBD::Oracle array interface - msg#00019

Previous Message by Date: click to view message preview

Re: DBD::mysql 3.0006 and 3.0006_1 released

Hi Patrick, As the community, one think you can do if you are interested in helping is to turn on server side prepare statements in 3.0006, or try the development driver, 3.0006_1 to see if there are any problems. I've found another problem with the new server side prepare statements in 3.0006_1. The attached program crashes here: mysql_st_prepare(sv * 0x0195b0a8, imp_sth_st * 0x0183b008, char * 0x01839470, sv * 0x0000002a) line 2311 + 21 bytes XS_DBD__mysql__st__prepare(cv * 0x0195850c) line 427 + 42 bytes [...] If I delete the " FOR UPDATE" from the SELECT statement then it outputs these errors instead: FREE ERROR BIND!FREE ERROR FBIND! If I turn off server side prepare then it works fine, with or without the " FOR UPDATE" clause. Cheers, - Steve PS. I didn't see any reply to my previous patch: http://www.xray.mpe.mpg.de/mailing-lists/dbi/2006-06/msg00111.html Please Cc me with any replies: I'm not subscribed to dbi-dev. ------------------------------------------------ Radan Computational Ltd. The information contained in this message and any files transmitted with it are confidential and intended for the addressee(s) only. If you have received this message in error or there are any problems, please notify the sender immediately. The unauthorized use, disclosure, copying or alteration of this message is strictly forbidden. Note that any views or opinions presented in this email are solely those of the author and do not necessarily represent those of Radan Computational Ltd. The recipient(s) of this message should check it and any attached files for viruses: Radan Computational will accept no liability for any damage caused by any virus transmitted by this email. use strict; use warnings; use DBI qw(:sql_types); my $tmp_dbh = DBI->connect( 'dbi:mysql:database=mysql', 'root', undef, { AutoCommit => 1, PrintError => 0, RaiseError => 1 } ); $tmp_dbh->do('CREATE DATABASE IF NOT EXISTS test'); $tmp_dbh->disconnect(); my $dsn = 'dbi:mysql:database=test;mysql_server_prepare=1'; # Crashes #my $dsn = 'dbi:mysql:database=test;mysql_emulated_prepare=1'; # OK my $dbh = DBI->connect( $dsn, 'root', undef, { AutoCommit => 1, PrintError => 0, RaiseError => 1 } ); $dbh->do('DROP TABLE IF EXISTS foo'); $dbh->do(qq{CREATE TABLE foo ( id INT NOT NULL AUTO_INCREMENT PRIMARY KEY, num INT ) ENGINE=InnoDB}); $dbh->trace(3, 'dbitrace.txt'); my $sql = 'SELECT num FROM foo WHERE id = ? FOR UPDATE'; my $sth = $dbh->prepare($sql); $sth->bind_param(1, 1); $sth->execute(); my $rows = $sth->fetchall_arrayref({}); $sth->finish(); $dbh->disconnect();

Next Message by Date: click to view message preview

[PATCH] DBI::TINYINT constant used instead of DBI::SQL_TINYINT

I think that DBD::File at line 392 has a mistake in DBI::SQL_TINYINT() constant name. Attached is a patch against DBI 1.51 (and DBD::File v0.34) that should solve this problem. The actual result of this problem is the following error message: Can't locate auto/DBI/TINYINT.al in @INC (@INC contains: ... .) at /opt/perl/lib/site_perl/5.8.6/x86_64-linux/DBD/File.pm line 384 I didn't understand clearly what triggers the error, may be the `quote($value, $type)' call? If useful to you, I can also file a bug on rt.cpan.org. -- Cosimo diff -u -Naur DBI-1.51/lib/DBD/File.pm DBI-1.51_cosimo/lib/DBD/File.pm --- DBI-1.51/lib/DBD/File.pm 2005-03-14 17:39:17.000000000 +0100 +++ DBI-1.51_cosimo/lib/DBD/File.pm 2006-06-27 09:54:36.087829379 +0200 @@ -389,7 +389,7 @@ $type == DBI::SQL_FLOAT() || $type == DBI::SQL_REAL() || $type == DBI::SQL_DOUBLE() || - $type == DBI::TINYINT())) { + $type == DBI::SQL_TINYINT())) { return $str; } if (!defined($str)) { return "NULL" }

Previous Message by Thread: click to view message preview

Re: Testing DBD::Oracle array interface

Thanks Andy that is great. I am finding a few things as I test on other boxes as well (Lunix and windows). Would you be so kind as to send me details on your test rig that is one area where my resources as a little limited. Cheers. ----- Original Message ----- From: "Andy Hassall" <andy@xxxxxxxxxxx> To: "John Scoles" <scoles@xxxxxxxxxxx> Cc: <dbi-dev@xxxxxxxx> Sent: Wednesday, June 07, 2006 11:29 AM Subject: Re: Testing DBD::Oracle array interface > > I have managed to add support for the Oracle Array Interface in > > DBD::Oracle. > > The original code comes from an old patch that Kristian Nielsen had > > created > > a while back but never seem to get into the to trunk. > > > > I was hoping someone could do a benchmark type test on loading many > > thousand > > or millions or records, as this seem to be what people want to use the > > interface for. > > I'm very interested in this, but for a slightly different reason - I > don't have huge data volumes, just hundreds to maybe a few thousand rows > at a time, but in one particular process I am having to connect over a > medium latency (120ms) transatlantic network link. The network overheads > for single rows inserts are killing performance here. > > Tried compiling on Cygwin to start with; this failed as an earlier change > in LOB support didn't add some lines to oci.def - patch attached to fix > it (this applies to both trunk and array branch). > > Have also now compiled and tested on Solaris; results from a simple test > inserting batches of 1000 rows to a remote database: > > Rate singlerow arrayinterface > singlerow 4.76/s -- -87% > arrayinterface 35.7/s 650% -- > > So that looks quite promising. > > thanks, > -- > Andy Hassall / <andy@xxxxxxxxxxx> / <http://www.andyh.co.uk> > <http://www.andyhsoftware.co.uk/space> Space: disk usage analysis tool

Next Message by Thread: click to view message preview

unique_key_info method?

Hi all, For context, I'm working on DBIx::Class::Schema::Loader, which is an automagic loader for the DBIx::Class object<->relational mapper - it examines a live $dbh and constructs matching classes and relationships between them. I'm trying to (as much as possible) get away from having explicit support for individual DBD's, and use generic standarized methods documented in DBI.pm in standard ways, so that it can work with any DBD which supports those methods, even ones we never planned for. This means making use of DBI methods like "tables", "primary_key_info", "foreigh_key_info", etc where possible in place of custom DBD-specific SQL statements. One method that I'd like to see, but which doesn't exist yet, is a "unique_key_info" similar to "primary_key_info", which after being released in the DBI dist, the DBD authors could work on supporting like they do "primary_key_info". Has this idea been shot down before? Is anyone already working on it? Would you mind me working up a patch for this and sending it in? -- Brandon