> Date: Thu, 27 Oct 2011 18:42:23 +0100
> From: martin.ev...@easysoft.com
> To: dbi-users@perl.org
> Subject: Re: DBI-Users> RE: DBD-Oracle - obtaining OCI handles from $dbh
>
> On 27/10/2011 17:43, John Scoles wrote:
> > Hmm....!!
> >
> > Well yes could be done but not as part of any release of DBD::Oracle it
> > would have to be you own hacked version
> >
> Why is that John? What is the problem with returning a C pointer via a
> DBD::Oracle attribute? It is just a pointer to some memory and loads of
> XS modules do this.
I have no real problem with this either i guess here I am talking about calling
his functions from XS as I denonstrated below.
>There is an Oracle OCI module I played with for a
> short time but it is problematic to build. I looked at it as I could
> implement OCI calls separately from DBD::Oracle. I don't seem the harm
> in exposing OCI handles via DBD::Oracle - it would be useful for people
> like the OP.
>
Oh yeah the old code of Tim B. Never could get it to compile for me. I think
the make file is only a few lines long and is only for 9i
> > A few pointers to start.
> >
> > You will not be able to 'get' a handle and retrun it as a Scalar it will
> > only ever be a pointer so you will just get some sort of number,
> >
> > You would simly edit the Oracle.xs file
> >
> > add in the includes to your C++ .h files
> >
> > then add a few extra
> >
> > 'ora_'
> >
> > functions to take care of you C++ calls;
> >
> > A quick example
> >
> > void
> > ora_some_c_call(dbh)
> > SV *dbh
> > PREINIT:
> > D_imp_dbh(dbh); //this gets all the OCI handles for you (see dbdimp.h for
> > the sturct imp_dbh_st)
> > CODE:
> > MYSomeC_Plus_Plus_method(dbh->envhp,dbh->svchp,dbh->seshp,dbh->srvhp);
> >
> >
> He does not need to do this surely. So long as the C++ code and
> DBD::Oracle XS is running in the same process the pointers obtained from
> DBD::Oracle are just as valid in the C++ code as XS. However, if the
> code is multi-threaded there could be issues of multiple threads
> accessing the OCI handles at the same time.
>
> >
> > Myself I would write a small 'c' wrapper that would call you c++ and just a
> > single .XS function that calls that small 'c' wrapper to fire your function.
> >
> My impression was that this was already done.
> I quote:
>
> "I have created some Perl bindings for some existing custom C++ libraries."
>
I guess I am just reading it differntly than you.
Anway best would be to see some prototye code so we can get an better Idea of
what he wants done.
If you just need the pointers to the OCI handles I think there is a way to have
a look at them in Perl. Seems I remember doing that or seeing it done one day
but that would be a real hack.
I will have to look at some code at home. It may involve getting a little to
deep into the exe tree.
cheers
John
> Martin
> --
>
> Martin J. Evans
> Easysoft Limited
> http://www.easysoft.com
>
>
> > Hope this helps
> >
> > Cheers
> > John
> >
> >
> >> Date: Thu, 27 Oct 2011 09:48:54 -0400
> >> From: bro...@deseret.com
> >> To: byter...@hotmail.com
> >> CC: dbi-users@perl.org
> >> Subject: Re: DBI-Users> RE: DBD-Oracle - obtaining OCI handles from $dbh
> >>
> >> Yes, I assumed I would need to extend DBD::Oracle is some manner
> >> to allow those handles to be extracted from a $dbh object.
> >>
> >> The specific OCI handles that the C++ libraries use are
> >>
> >> - Environment handle
> >> - Service Context handle
> >> - Session handle
> >> - Server handle
> >>
> >> My initial thought process on how it might work is this
> >>
> >> Create a method in the DBD::Oracle XS code to retrieve those
> >> handles and return them back to Perl space as a scalar.
> >>
> >> Then with the Perl scalars that hold the OCI handles obtained from
> >> $dbh, pass those values to my Perl bindings to the custom C++ libraries.
> >> (I would need to extend the C++ libraries to allow the set methods
> >> to the objects that hold those OCI handles).
> >>
> >> ...then the C++ libraries should work the same.
> >>
> >> The motivation for this approach is that I have a large code base
> >> of these C++ libraries that have been tested, so it would cost
> >> prohibitive to simply replace them with a pure Perl implementation.
> >>
> >> However, it is so much easier to work with Perl and DBI, it would
> >> be useful to have DBI connect to the database and do some table
> >> lookups. The C++ code could then be integrated seemlessly with my
> >> Perl code. As time allows, I would gradually peel away functionality
> >> from the legacy C++ libraries and implement it in Perl. But to
> >> ease the migration path, this approach seemed to have some merits.
> >>
> >>
> >> Quoting John Scoles (byter...@hotmail.com):
> >>>
> >>>
> >>>
> >>>> Date: Wed, 26 Oct 2011 21:46:30 -0400
> >>>> From: bro...@deseret.com
> >>>> To: dbi-users@perl.org
> >>>> Subject: DBD-Oracle - obtaining OCI handles from $dbh
> >>>>
> >>>> I have created some Perl bindings for some existing custom C++
> >>>> libraries.
> >>>>
> >>>> One of these C++ libraries implements a class that uses Oracle
> >>>> OCI calls.
> >>>>
> >>>> I would like to create a connection to the Oracle database
> >>>> using Perl's DBI (DBD::Oracle) module, and then ideally share
> >>>> that connection with the C++ libraries.
> >>>>
> >>>> This would require me to extract the Oracle OCI handles from
> >>>> the $dbh object...and then pass them to the C++ libraries.
> >>>>
> >>>> What would be the best way to get access to the underlying
> >>>> Oracle OCI handles from a $dbh object?
> >>> Hmm! Interesting concept. Which OCI handles are we talking about??
> >>> Like Matin said you would have to do that with .XS and you would pass I
> >>> guess a pointer to the
> >>> 'C' struct that holds the pointers to DBD::Oraclles pointers?
> >>>
> >>> You would have to cast that struct into you C++ somehow??
> >>>
> >>> There would be a good number of handles to pass over. You might be able
> >>> to find them by looking at the Perl process tree
> >>> and finding the SV that holds the struct and then sening that over?
> >>>
> >>> All just guesses on my part.
> >>>
> >>> Interesting concept non the less.
> >>>
> >>> Cheers
> >>> John
> >>>
> >
>
