Re: Memoizing non-place-holding sql statements to place-holding
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
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?
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
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
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?
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.
