DBD::Oracle and various oracle clients

I would like to be able to use various DBD::Oracle drivers
one using the client library for oracle 8.1.7.x
and another using the client library for oracle 9.2.x

one (ugly) way would be to build twice DBD::Oracle and then
sistematically change one of the tree to have (say) DBD::Oracle8...

another way would be to subclass in a smart way...
is this doable? anybody maintaining various DBI/Oracle combinations that
could give insight

thanks
--stephan

Re: DBD::Oracle and various oracle clients

Stephan Titard wrote:
> I would like to be able to use various DBD::Oracle drivers
> one using the client library for oracle 8.1.7.x
> and another using the client library for oracle 9.2.x

Why?

Re: DBD::Oracle and various oracle clients

Stephan Titard writes:

> I would like to be able to use various DBD::Oracle drivers
> one using the client library for oracle 8.1.7.x
> and another using the client library for oracle 9.2.x

Easy - just use the PREFIX or LIB options to "perl Makefile.PL" to install
them in different locations. Then "use lib" in your script to add one or
the other location to Perl's module search path.

Have a look at "perldoc perlmodinstall" for details.

sherm--

--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net

Re: DBD::Oracle and various oracle clients

Achim Grolms escribió:
> Stephan Titard wrote:
>> I would like to be able to use various DBD::Oracle drivers
>> one using the client library for oracle 8.1.7.x
>> and another using the client library for oracle 9.2.x
>
> Why?
the same perl tree is used to access different versions of oracle.

sherm's idea in this thread is to have DBD::Oracle and for example
DBDOracle8::DBD::Oracle tweaking PREFIX (or DBD::Oracle8::DBD::Oracle)

thanks
--stephan

Re: DBD::Oracle and various oracle clients

Sherm Pendley escribió:
> Stephan Titard writes:
>
>> I would like to be able to use various DBD::Oracle drivers
>> one using the client library for oracle 8.1.7.x
>> and another using the client library for oracle 9.2.x
>
> Easy - just use the PREFIX or LIB options to "perl Makefile.PL" to install
> them in different locations. Then "use lib" in your script to add one or
> the other location to Perl's module search path.
>
> Have a look at "perldoc perlmodinstall" for details.
>
> sherm--
>
Yes, but this implies having e.g DBDOracle8::DBD::Oracle or even
DBD::Oracle8::DBD::Oracle, a bit ugly...
it has implications with respect to the automatic discovery of drivers
by DBI (dbi:Oracle:host -> dbi:Oracle8174:host etc...)

I would have liked DBD::OracleXXX
maybe I could make DBD::Oracle8 a proxy for DBDOracle8::DBD::Oracle
I have to look into that (maybe use some of the tricks of the 'aliased'
module)
almost seems safer to transform the code.

thanks
--stephan

Re: DBD::Oracle and various oracle clients

> Yes, but this implies having e.g DBDOracle8::DBD::Oracle or even
> DBD::Oracle8::DBD::Oracle, a bit ugly...
> it has implications with respect to the automatic discovery of drivers
> by DBI (dbi:Oracle:host -> dbi:Oracle8174:host etc...)
>
> I would have liked DBD::OracleXXX
> maybe I could make DBD::Oracle8 a proxy for DBDOracle8::DBD::Oracle
> I have to look into that (maybe use some of the tricks of the 'aliased'
> module)
> almost seems safer to transform the code.
>
> thanks
> --stephan
actually this is a generic question how to have A::B install as A1::B1
(not A::B)
or make A::B completely equivalent to MY::A::B (this must work for
procedural o OO interface)

hth
--stephan

Re: DBD::Oracle and various oracle clients

Stephan Titard wrote:
> Achim Grolms escribió:
>> Stephan Titard wrote:
>>> I would like to be able to use various DBD::Oracle drivers
>>> one using the client library for oracle 8.1.7.x
>>> and another using the client library for oracle 9.2.x
>>
>> Why?
> the same perl tree is used to access different versions of oracle.

Sure. But why?

One idea is to install DBD::Oracle to different PREFIX locations
and use PERL5LIB, ORACLE_HOME and LD_LIBRARY_PATH
to configure the correct locations of Perllibs and
Oracle-code.

Re: DBD::Oracle and various oracle clients

Stephan Titard writes:

> Sherm Pendley escribió:
>> Stephan Titard writes:
>>
>>> I would like to be able to use various DBD::Oracle drivers
>>> one using the client library for oracle 8.1.7.x
>>> and another using the client library for oracle 9.2.x
>>
>> Easy - just use the PREFIX or LIB options to "perl Makefile.PL" to install
>> them in different locations. Then "use lib" in your script to add one or
>> the other location to Perl's module search path.
>>
>> Have a look at "perldoc perlmodinstall" for details.
>>
>> sherm--
>>
> Yes, but this implies having e.g DBDOracle8::DBD::Oracle or even
> DBD::Oracle8::DBD::Oracle

No, it doesn't.

> it has implications with respect to the automatic discovery of drivers
> by DBI (dbi:Oracle:host -> dbi:Oracle8174:host etc...)

No, it doesn't.

Please - read "perldoc perlmodinstall" to see what PREFIX and LIB *really*
do before making further incorrect assumptions.

sherm--

--
Web Hosting by West Virginians, for West Virginians: http://wv-www.net
Cocoa programming in Perl: http://camelbones.sourceforge.net

Re: DBD::Oracle and various oracle clients

> Please - read "perldoc perlmodinstall" to see what PREFIX and LIB *really*
> do before making further incorrect assumptions.
>
> sherm--
>

Sherm, I just re-read the perlmodinstall to see if I missed something
obvious (after all these years) , but you just lost me...
PREFIX, LIB and use lib permit to have various directories acting as one
single hierarchy where to find modules, i.e module A::B is
/A/B.pm etc
(they deal with the mechanics of installing, not the dynamics of using)

where is the second DBD::Oracle rooted?
how do I 'use' both at the same time?

maybe my original question was poorly phrased...sorry
of course I can encapsulate in various .pm

use lib /where/is/oracleXXX;
use DBD::Oracle;

but it is not what I was asking for.

thanks
--stephan

Re: DBD::Oracle and various oracle clients

Stephan Titard wrote:
>
>> Please - read "perldoc perlmodinstall" to see what PREFIX and LIB *really*
>> do before making further incorrect assumptions.
>>
>> sherm--
>>
>
> Sherm, I just re-read the perlmodinstall to see if I missed something
> obvious (after all these years) , but you just lost me...
> PREFIX, LIB and use lib permit to have various directories acting as one
> single hierarchy where to find modules, i.e module A::B is
> /A/B.pm etc
> (they deal with the mechanics of installing, not the dynamics of using)
>
> where is the second DBD::Oracle rooted?
> how do I 'use' both at the same time?

What means "at the same time"?
In the same process?

Re: DBD::Oracle and various oracle clients

Achim Grolms escribió:
> Stephan Titard wrote:
>> Achim Grolms escribió:
>>> Stephan Titard wrote:
>>>> I would like to be able to use various DBD::Oracle drivers
>>>> one using the client library for oracle 8.1.7.x
>>>> and another using the client library for oracle 9.2.x
>>> Why?
>> the same perl tree is used to access different versions of oracle.
>
> Sure. But why?
>
> One idea is to install DBD::Oracle to different PREFIX locations
> and use PERL5LIB, ORACLE_HOME and LD_LIBRARY_PATH
> to configure the correct locations of Perllibs and
> Oracle-code.
Well I try always to minimize the use of env. vars, especially
SHLIB_PATH, LD_LIBRARY_PATH and the such.

On HP-UX (11.0 32bit) I build a distribution with about 350 modules where
all external shared objects are found (modulo one symlink) directly
inside the perl tree
so that it is ready for tar and independent. In the case of a (perl)
built shared library
with external dependency (like DBD/oracle.sl) I create a link to the
external library inside my perl-tree that I use for the install of the
perl module. finally an external OS-dependent command is used to turn
off the use of SHLIB_PATH and the such.

why? "principle of least surprise, probably and KISS too"

I use a couple ugly tricks like to relocate a fresh build
to another place: I build normally for /opt/perl58X (core + modules)
and I "generate" for /var/tmp/p*/perl58X (the core part is actually
installed normally using PREFIX). In all the *sl I reserved enough room
in the shared object header using ///////external/shared/object
which I subsistute directly in the binary.
Does not work yet for solaris, but is mainly ok on cygwin.


hth
--stephan

Re: DBD::Oracle and various oracle clients

Achim Grolms escribió:
> Stephan Titard wrote:
>>> Please - read "perldoc perlmodinstall" to see what PREFIX and LIB *really*
>>> do before making further incorrect assumptions.
>>>
>>> sherm--
>>>
>> Sherm, I just re-read the perlmodinstall to see if I missed something
>> obvious (after all these years) , but you just lost me...
>> PREFIX, LIB and use lib permit to have various directories acting as one
>> single hierarchy where to find modules, i.e module A::B is
>> /A/B.pm etc
>> (they deal with the mechanics of installing, not the dynamics of using)
>>
>> where is the second DBD::Oracle rooted?
>> how do I 'use' both at the same time?
>
> What means "at the same time"?
> In the same process?
Yes. sloppy wording again:
I meant in the same perl file one use behind the other like in

use DBD::Oracle;
use DBD:Whatever;

Re: DBD::Oracle and various oracle clients

> On HP-UX (11.0 32bit) I build a distribution with about 350 modules where
> all external shared objects are found (modulo one symlink) directly
> inside the perl tree
> so that it is ready for tar and independent. In the case of a (perl)
> built shared library
> with external dependency (like DBD/oracle.sl) I create a link to the
> external library inside my perl-tree that I use for the install of the
> perl module. finally an external OS-dependent command is used to turn
> off the use of SHLIB_PATH and the such.
>
> why? "principle of least surprise, probably and KISS too"
>

actually, Nicholas Clark has been doing lately work on the relocation
problem
of a core distribution (see p5p about 2 months ago)
it is not easy and the double dependency problem is not handled
completely (as far as I can tell for HP-UX and external modules)