Re: Memoizing non-place-holding sql statements to place-holding

2005-09-26 Thread Jonathan Leffler
On 9/25/05, Steven Lembark [EMAIL PROTECTED] wrote:

  This coding may not be so difficult, but not easy for me.

 The issue will be converting:

 insert into foo ( field, fields ) values ( ... );

 into

 insert into foo ( field, fields ) values ( ?, ?, ? )



...especially if one of the values happens to be a SELECT statement, or a
function call, or something equally fun?

INSERT INTO WhatNot VALUES (1, abc, (SELECT dismal FROM failure WHERE
antidote = 'mercury'), MDY(MONTH(TODAY), 1, YEAR(TODAY) + 2));

This may or may not be standard SQL; it is practical SQL for at least some
DBMS.

--
Jonathan Leffler [EMAIL PROTECTED] #include disclaimer.h
Guardian of DBD::Informix - v2005.02 - http://dbi.perl.org
I don't suffer from insanity - I enjoy every minute of it.


Can't locate loadable object for module DBI in @INC

2005-09-26 Thread Anurag Vidyarthi
Hi,

I m installing the bugzilla s/w for bugtracking. I requires following 3
software components :

 

I have installed mysql at /usr/local/mysql-4.1.14

I have installed perl at /usr/local/perl-5.8.7

I have installed many perl modules /usr/local/perl_modules

(All are compiled from the source)

 

Mysql and apache are tested as well.

 

but I am hitting the following error when I am running the following
command in bugzilla directory :-

./testserver.pl http://10.50.1.101/bugzilla-2.18.3

where bugzilla-2.18.3 is the virtual directory defined in httpd.conf
file of apache.( I have installed apache in /usr/local/apache directory)


It gives the following error:

Can't locate loadable object for module DBI in @INC (@INC contains:
/usr/local/perl_modules/DBI-1.40 . /usr/perl5/5.00503/sun4-solaris
/usr/perl5/5.00503 /usr/perl5/site_perl/5.005/sun4-solaris
/usr/perl5/site_perl/5.005 .) at /usr/local/perl_modules/DBI-1.40/DBI.pm
line 252
BEGIN failed--compilation aborted at
/usr/local/perl_modules/DBI-1.40/DBI.pm line 252.
BEGIN failed--compilation aborted at Bugzilla/DB.pm line 31.
BEGIN failed--compilation aborted at globals.pl line 31.

But I have installed DBI at /usr/local/perl_modules/DBI-1.40
by the commands :

perl Makefil.PL
make
make install

and then subsequently DBD as well without any error .
I have changed the DB.pm in bugzilla directory

use lib /usr/local/perl_modules/DBI-1.40;
use DBI;

to asked it to go the module where DBI is installed but I do not know
why it is not loading the DBI objects from there.

Is there anybody who can help me out.




With regards 
anurag vidyarthi
[EMAIL PROTECTED]

 



Re: Subclassing the DBI - any good examples?

2005-09-26 Thread John Siracusa
On 9/26/05 5:01 AM, Tim Bunce wrote:
 Anyone else have a DBI subclassing story to tell?

My story is short: I never seriously attempted it because I knew how scary
and non-standard DBI was internally.  Several times in my misspent youth I
wanted to do something simple like:

package MyDBI;
use DBI;
our @ISA = qw(DBI);
sub connect
{
  my $class = shift;
  ...; 
  $class-SUPER::connect(...);
}

but, of course, that doesn't quite work out.  I think the best argument for
subclassing DBI is that people (initially) expect it to work, so it should.
There's no sense in trying to predict why people will want to subclass.
Just make sure it's straightforward, and let the actual instances of
subclassing bloom... :)

-John




Re: DBI dies on exit

2005-09-26 Thread Alan Burlison
I've poked at this a bit more - if I install the full client it works 
OK, which suggests there is something odd in the way the client shared 
objects are being linked - a full install relinks the .so files but the 
instant client install doesn't.  I'll try dropping the relinked shared 
objects into the instant client tree and see if that makes the problem 
go away.


Tim, has there been any progress on getting DBD::Oracle to work with an 
Instant Client install?  How much work do you think it is, I might be 
persuaded to produce a patch ;-)


--
Alan Burlison
--


Anyone seen this?

--
#!/usr/perl5/bin/perl
use DBI;
my $dbh = DBI-connect('dbi:Oracle:foo', 'bar', 'baz');
$dbh-disconnect();
--

Out of memory!
Callback called exit.
END failed--call queue aborted.

The environment is Solaris 11 on AMD64, using the latest Oracle 32-bit 
instantclient and DBD::Oracle 1.16.  The script is barfing in 
perl_destroy(), i.e. after the disconnect() statement.  Before I get the 
rubber gloves out, has anyone seen anything similar?


Nope.

Callback called exit is very odd but may just be a symptom of Out of
memory ocuring during perl_destroy(). But then that, in itself, is odd.

You'll need the gloves on for this one...

Tim.


Fwd: Announcing MySQL 5.0 Release Candidate

2005-09-26 Thread Darren Duncan
Users of the MySQL database manager should find 
this interesting.  MySQL 5 is in release 
candidate status.


Besides the obvious big ticket new features, I 
would find the information schema and strict 
mode etc features very useful.  The former is a 
very good and standard way to get meta-data on 
your tables and such; meta-data being something 
that lots of DBI wrapper modules need to operate.


-- Darren Duncan



Date: Mon, 26 Sep 2005 19:41:07 +0300
From: Kaj Arnö [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Subject: Announcing MySQL 5.0 Release Candidate

Dear user of MySQL,

I'm proud and excited to announce the first Release Candidate of MySQL
5.0. This milestone signals that we are nearing what is certainly the
most important release in MySQL's history.

MySQL 5.0 has new functionality that I hope will be welcomed, adopted,
and put to productive use by the community of MySQL users -- you. On the
commercial side, MySQL AB is getting a lot of good vibes from new
enterprise customers who are beginning to understand the impact MySQL
can have on their IT infrastructure and costs of running
mission-critical applications.

The betas of MySQL 5.0 have already been downloaded two million times,
and have thus been tested extensively in a lot of different scenarios.
From the feedback we get from our community, we know it is already in
production use at numerous sites. Go get your own copy at
http://dev.mysql.com/downloads/mysql/5.0.html

Without question, MySQL 5.0 is the most ambitious release to date for
MySQL AB. Of course, everything we do at MySQL centers around our three
priorities of Performance, Reliability, and Ease of Use.  Version 5.0 of
MySQL is certainly true to these company-wide imperatives.

Key new features of MySQL 5.0 come in three groups:

a) ANSI SQL standard features formerly unknown to MySQL
b) ANSI SQL standard compliance of existing MySQL features
c) New MySQL Storage Engines, Tools and Extensions

The new ANSI SQL features include:

- Views (both read-only and updatable views)
- Stored Procedures and Stored Functions, using the SQL:2003 syntax,
  which is also used by IBM's DB2
- Triggers (row-level)
- Server-side cursors (read-only, non-scrolling)

Implementing ANSI SQL standard ways of using existing MySQL features
means there will be fewer unpleasant surprises (gotchas) for those
migrating to MySQL from other database systems:

- Strict Mode: MySQL 5.0 adds a mode that complies with standard SQL
  in a number of areas in which earlier versions did not; we now do
  strict data type checking and issue errors for all invalid dates,
  numbers and strings as expected
- INFORMATION_SCHEMA: An ANSI SQL-compliant Data Dictionary for
  accessing metadata, in parallel to the MySQL specific SHOW
  commands
- Precision Math: A new library for fixed-point arithmetic, giving
  high accuracy for financial and mathematical operations
- VARCHAR Data Type: The maximum effective length of a VARCHAR column
  has increased to 65,532 bytes; also, stripping of trailing whitespace
  no longer occurs

New MySQL Storage Engines, Tools and Extensions are:

- XA Distributed Transactions
- ARCHIVE Storage Engine for storing large amounts of data without
  indexes in a very small footprint, intended for historical data that
  may be needed for future audit compliance (Sarbanes Oxley or
  otherwise)
- FEDERATED Storage Engine for accessing data ín tables of remote
  databases rather than in local tables (only in MAX version)
- Instance Manager: a tool to start and stop MySQL Server, even remotely

To find out more details on what's new in MySQL 5.0, follow the pointers
from http://dev.mysql.com/doc/mysql/en/mysql-5-0-nutshell.html

To find out the changes specific to MySQL 5.0.13 
in relation to 5.0.12, see 
http://dev.mysql.com/doc/mysql/en/news-5-0-13.html


MySQL 5.0 is also reflected in our GUI tools and Connectors:

MySQL Administrator 1.1.3 and MySQL Query Browser 1.1.15 are aware of
the new MySQL 5.0 features, can be used to write and test stored
procedures, create views, include them in scheduled backups and much more.

The latest shipping versions of our Connectors work with MySQL 5.0, and
all connectors (MySQL Connector/ODBC, Connector/J and Connector/NET)
will support all flagship features before 5.0 goes GA.

We're pleased that we've reached a point of stability where it's been a
while since we received a significant inflow of bugs that drastically
impacted a large number of users. Of course, we recognize we haven't
crossed the finish line yet, so we still very much need your involvement
to ensure that MySQL 5.0 is the best that it possibly can be.

With MySQL 5.0 being that stable, I encourage you to do all of your new
database development using MySQL 5.0:

1. Download 5.0 from http://dev.mysql.com/downloads/mysql/5.0.html
2. Use the new features you need
3. Report any issues you find through our bug-reporting system at
   http://bugs.mysql.com/.

To show our appreciation for 

Re: Subclassing the DBI - any good examples?

2005-09-26 Thread Henri Asseily


On Sep 23, 2005, at 3:19 PM, Tim Bunce wrote:


I'm interested to hear stories of people who have subclassed the DBI,
or used modules that subclass the DBI.

Was subclassing the DBI a good approach?

Where there any problems?

Could it have been done well/better some other way?

Thanks!

Tim.




I subclassed DBI for DBIx::HA, a high-availability module.
I subclassed connect(), prepare() and execute().

The new connect() takes as input a stack of DSNs with its associated  
meta info (timeouts, type of failover, etc...) and determines which  
DSN to connect to based on availability and inter-process communication.


The prepare() and execute() are subclassed to trap errors and kick  
back to reconnect, then reprepare and reexecute into another DSN.


Who is using it:
We're internally using it very heavily. I know of one other external  
person/group using the module.


What went well:
It solved many problems, one of which was to be able to use Sybase  
OpenSwitch (a load balancer/failover proxy for Sybase ASE) with DBI.  
Other problems solved were the ability to automatically failover in  
case of hard database failure, and an easy failback mechanism that  
doesn't necessitate an Apache restart under mod_perl.
Subclassing the DBI looked like an easy approach at first, and I was  
able to get most needed functionality quickly and easily.


Problems:
There were many painful issues to deal with: signal handling,  
trapping of errors, making sure the database behaves properly,  
remembering the state of the query, etc...
At this point I can't guarantee even that I've nailed all possible  
race conditions. It's extremely difficult to debug all the use cases.


Could it have been done a better way?
Absolutely. I think that this whole high availability layer should be  
at the driver level as a proxy driver, ultimately part of  
DBD::Multiplex.
In fact DBIx::HA couldn't have worked at all without the added  
functionality in DBI of swap_inner_handle(), but even with that I ran  
into a wall where I didn't have enough control over the row-level  
info that a proper DBD driver would have.