Re: OOP Access of variables

I think I'm missing something here, but isn't this as easy as making sure that TartLib's dbi connection variable is in the EXPORT list, or you provide a function that returns it if you want better encapsulation?: eg...

my $sth = TArtLib::dbi->prepare("select * from table") or die DBI::err
+str;
my $sth2 = TArtLib->dbi()->prepare("select * from table") or die DBI::
+errstr;
[download]

What's confusing is that you say you want it from the persistent connection from the command line as you'd get from running Apache::DBI. Unless you have an aspect of your program that will be running constantly acting as a server, I don't see how you can get this, as TArtLib will be initialized every runtime from the command line, reconnecting it to the database. Maybe I'm just mistaken here.

Dr. Michael K. Neylon - mneylon-pm@masemware.com || "You've left the lens cap of your mind on again, Pinky" - The Brain

Comment on Re: OOP Access of variables Download Code

Replies are listed 'Best First'.
Re: Re: OOP Access of variables by simeon2000 (Monk) on Mar 08, 2001 at 21:27 UTC
Sorry, I must not have made it clear. I mean, each time the main script is run, I only want one instance of the database connection. This is created in TArtLib ($TArtLib::dbh). I want TArt::Editor to be able to use $TArtLib::dbh, so that TArt::Editor doesn't need to make a new DB connection. Both TArtLib and TArt::Editor will/should always be used in package main.	[reply]
Re: Re: Re: OOP Access of variables by simeon2000 (Monk) on Mar 08, 2001 at 21:29 UTC
... the reason being, if I have 40 editor objects, I don't want 40 database handles. I'd like all 40 TArt::Editor objects to use TArtLib's DB connection.	[reply]