You are viewing a plain text version of this content. The canonical link for it is here.
Posted to asp@perl.apache.org by Stephen Bardsley <sb...@rlwinc.com> on 2002/09/16 23:11:17 UTC
dynamic module
Greetings:
I have been struggling with something and I hope
someone can set me straight.
<%
I have a perl module, which contains a database
handle (dbh).
I would like to use this module under Apache::ASP.
I would like to have users dynamically define a database
for the module to connect to. I can/will constrain
the lifetime of the module to that of an Apache::ASP
$Session.
The trouble I am having is that I cannot maintain
the coherence of the dbh in the module. Sometimes
the dbh is defined and sometimes not. I have used
this module successfully in other Apache::ASP
applications, but the database has always been
statically defined to the module.
Is there a way to allow the user to define the
database to the module?
%>
Any suggestions will be greatly appreciated.
Steve
_____________________
Stephen Bardsley
RLW Inc.
Malta, NY
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: dynamic module
Posted by Brat Wizard <br...@naxs.com>.
On Tuesday 17 September 2002 01:54 am, Stephen Bardsley spewed into the ether:
> Hi John:
>
> It's ironic how similar our applications seem!
>
> I have a perl module that wraps around DBI, and
> get this, it is called Db.pm also.
Hmm- I contacted the naming committee, they took the matter under advisement,
generated half-a-dozen candidates, handed it off to the selection committee
(which by some quirk, only meets the second tuesday following a full moon)
who selected three finalists then handed everything off to management, legal,
and marketing research, who in turn rejected one right out (for unspecified
legal reasons I think it was), and another after two independent (and
double-blind-- from-birth apparently) focus groups gave it a pass-- until
finally they settled on the one we didn't use. So we ended up with "Db.pm"
instead. Your way seems a little easier, I may try that next time ;)
> If you are able to use global vars (use vars) in
> your subs with no problem, then I've some work ahead
> of me. I think it points to the fact that either I have
> a systematic problem with my code or I have uncovered a
> bug/feature in some of the underlying code.
Probably not a code failure. I think Josh may have a clue in his reply (I read
it before I saw yours).
> Thanks again.
No prob, that's what we're all here for-- so many people have helped me, its
nice to be able to help someone else for a change ;)
> Regards,
> Steve
John
--
--------------------------------------------------------------------------------
Check out http://www.Wizard.Org for great deals on Electronic Parts
*NEW* Computer Parts & Accessories - Drives - LCD - Systems - Linux
--------------------------------------------------------------------------------
** Affordable Online Store w/Merchant Card Processing & Paypal **
Write to us: sales@wizard.org -- Get your Store Online Today!
--------------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
RE: dynamic module
Posted by Stephen Bardsley <sb...@rlwinc.com>.
Josh:
I always have UseStrict on, but your suggestion of
turning on PerlWarn was like some cold water in the
face. I normally have it turned on, but not this time.
That simple step illuminated a number of silly little
issues that conspired to put my application in the
crapper. While it's still not perfect, I am back on
track adding value and not time.
Sometimes it's real nice to have someone looking over
your shoulder, thank you.
Also, as you probably suspected, this problem was
apparently related to my other post RE: strange error,
it has become remarkably better.
Thanks again.
Steve
> -----Original Message-----
> From: Josh Chamas [mailto:josh@chamas.com]
> Sent: Tuesday, September 17, 2002 2:36 AM
> To: Stephen Bardsley
> Cc: Apache::ASP Mailing List
> Subject: Re: dynamic module
>
>
> Stephen Bardsley wrote:
> > I'm still open for suggestions on what might cause a
> > global to be unreliable in subs or other .asp
> > scripts. Thanks again.
> >
>
> I recently discovered a combination of UseStrict setting
> with PerlWarn On can uncover some nasty errors like
> my closure variable scoping issues, that could be getting
> mistaken for globals & such. You might give those configs
> a try and see if anything breaks.
>
> Regards,
>
> Josh
> ________________________________________________________________
> Josh Chamas, Founder phone:925-552-0128
> Chamas Enterprises Inc. http://www.chamas.com
> NodeWorks Link Checking http://www.nodeworks.com
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: dynamic module
Posted by Josh Chamas <jo...@chamas.com>.
Stephen Bardsley wrote:
> I'm still open for suggestions on what might cause a
> global to be unreliable in subs or other .asp
> scripts. Thanks again.
>
I recently discovered a combination of UseStrict setting
with PerlWarn On can uncover some nasty errors like
my closure variable scoping issues, that could be getting
mistaken for globals & such. You might give those configs
a try and see if anything breaks.
Regards,
Josh
________________________________________________________________
Josh Chamas, Founder phone:925-552-0128
Chamas Enterprises Inc. http://www.chamas.com
NodeWorks Link Checking http://www.nodeworks.com
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
RE: dynamic module
Posted by Stephen Bardsley <sb...@rlwinc.com>.
Hi John:
It's ironic how similar our applications seem!
I have a perl module that wraps around DBI, and
get this, it is called Db.pm also. Not to worry,
it has a unique namespace prefix, so they will not
clash if ever they meet. A good thing for modules
I think. BTW -- I use the selective query tricks too.
It's a big help.
If you are able to use global vars (use vars) in
your subs with no problem, then I've some work ahead
of me. I think it points to the fact that either I have
a systematic problem with my code or I have uncovered a
bug/feature in some of the underlying code.
I'm still open for suggestions on what might cause a
global to be unreliable in subs or other .asp
scripts. Thanks again.
Regards,
Steve
> -----Original Message-----
> From: Brat Wizard [mailto:brat@naxs.com]
> Sent: Tuesday, September 17, 2002 12:50 AM
> To: Stephen Bardsley; Apache::ASP Mailing List
> Subject: Re: dynamic module
>
>
> > I want my variable to be valid and defined for the duration of a Session.
>
> Okay, that's what the session object is for, as you appear to already know. ;)
>
> > > example) is to use Apache::DBI. Apache::DBI will override the normal DBI
>
> > I am using and have used Apache::DBI with good results. I'm sorry, I
> > didn't mean to imply "on-the-fly" as from one script to the next. To be
> > more precise I meant from one Session to the next.
>
> Okay-- so if I'm understanding you correctly, connecting to the database each
> time the script is executed (a la Script_OnStart) is okay, so what is the
> problem with say storing the datasource parameters as session data and then
> using it to reconstitute the handle each time? You can't cache the handle
> itself, but you _can_ cache the name of the database connected to (and
> whatever host/user info you need) as session scalars (or a hash-- or even
> just store the actual DBI data source string itself if that's all you really
> need). Then just use that information the next time around to re-connect to
> the database.. Basically check to see if we've been connected before (ie. is
> $..dbname defined, or whatever). If not, store it. When you're done, close
> the connection and zap the data in the session variable (or abandon the
> session altogether). Then go through the process all over again for the next
> session..
>
>
> You didn't say, but perhaps you are concerned about caching selected data from
> a query and that's what the real bottom-line issue is?? (as in: why it would
> be interesting/useful to be able to store a db handle in the session object
> anyway...)
>
> This is a trick I often use.. if the query is expensive (a full-text search or
> something) and I don't want to have to rerun the query each time to get the
> next chunk of data-- what I will do is run the query and ONLY select the
> actual key(s) to the data itself in whatever order they're needed. (eg.
> SELECT key_field FROM table WHERE blah blah ORDER BY blah blah) Then blast
> the keys into a file-- several ways to do this quickly & effectively, the
> easiest is to simply create a key array and use Storable to freeze it in a
> file. Then you can just thaw it out later and use the list.
>
> By using a key array, you can construct a query retrieving _only_ the items
> needed for the specific page which is generally very fast (much much faster
> usually) compared to running the query all over again (eg. SELECT
> fields_i_need FROM table WHERE key=key1 or key=key2 or key=key3..etc) They
> are already in the correct order so you don't need the overhead of an "order
> by" clause.
>
> When you're through, dump the key array whenever its convenient (or don't if
> you don't care about disk space-- the frozen files are small, you can reap
> them at your leisure).
>
> If I'm displaying paged data, a simple rule I often employ is that either a
> new sort order (clicking on a column header for instance) or retrieving page
> zero will dump the cache & rerun the query (making a new key array). It
> generally works quite well, and I've been very pleasantly surprised at how
> small the frozen cache files are, even for large queries. And slurping up a
> frozen array is pretty darned quick. If you hide all the mechanical bits
> inside functions, pretty soon you forget how horrible a kludge this really is
> and it almost begins to seem normal :) ;)
>
>
> > > The next easiest thing to do is to figure out what database to connect to
> > > and open it each time the script runs (the Script_OnStart() function is a
>
> >
> > This is kind of what I am doing now, and can't quite get things working.
> > It seems it may actually be an issue with variable scoping. If I scope
> > my module's instance variable in the Script_OnStart things seem to work.
> > That is, I create the instance in Script_OnStart. If I create the
> > instance in one of global.asa's sub's then it does not seem to work
> > reliably. Bear in mind I am using global variables in global.asa
> > by way of "use vars qw( $var2 $var2 $etc );". If this is incorrect
> > or a better way exists, I'm all ears. Thanks again for your time.
>
> Hmm- interesting. I do it in subs all the time with no problems whatsoever. I
> declare the global variable the same way you do, "use vars qw( $db ... blah
> blah);" at the top of my global.asa file (and again in EVERY package file
> that is not a separate module-- not a separate namespace-- I break a lot of
> my code up into sub-files to keep it more manageable). The scope should be
> global. Might you have some my variable someplace that's stomping on the
> global version??
>
> I have a Db.pm module that I wrote that basically encapsulates most of the DBI
> stuff I use-- so keep that in mind in the short example below-- it isn't
> exactly what you're used to but it will be similar enough. In one of my
> global.asa files, the flow goes something like this:
>
> package Apache::ASP::STORES;
>
> use vars qw{ $db ... [more vars] };
> use lib Apache->request->dir_config('BaseDir')."/lib";
>
> use Apache::ASP;
> use Db;
>
> [more use statements]
>
> sub Script_OnStart {
> [..do stuff]
>
> connectToDB();
>
> [.. do more stuff.. ]
> }
>
> sub connectToDB {
> my $dbname = <my dbname>; ## actually declared elsewhere
> my $dbhost = <my host>; ## for me, but you get the idea
> return if ($db ne undef); ## got a handle thanks, don't need another
> $db = new Db;
> $db->Connect($dbname, $dbhost);
> return $db;
> }
>
>
> In this case, the $db handle that gets returned is of my own "db" style that I
> mentioned. But it only wraps around the usual dbh handle and is mostly
> exposed except for wrapping commonly used constructs to make slapping
> together code quicker, easier, and a bit more mindless. Its pretty easy
> actually, even my cat could do it... (as it happens, I walked into the
> computer room one day and there he was sitting building a database cataloging
> north american migratory birds and cross-referencing them by recipe... but
> that's another story altogether ;)
>
>
> Hope this helps-
>
> John Whitten
> brat@naxs.com
> Wizard.Org, Inc.
>
>
>
> >
> > > The best way (but not necessarily the easiest) is to use some sort of
> > > middleware such as SQLrelay or something similar that will sit between
> > > your perl application and the database, maintain open connections and
> > > drop or establish new connections as demanded. SQLrelay is a neat thing
> > > but it is a pain-in-the-ass (IMO) to install and configure. (I should
> > > also point out that my experience with it is some 6+months old so a newer
> > > version which may address some of these issues may be available?)
> > > SQLrelay works with just about any database DBI can work with, and in
> > > addition can work across servers, and I *think* (perhaps it was a planned
> > > feature, in any case I never used it myself) it had auto-failover support
> > > in case one server didn't answer up-- won't swear to that though- perhaps
> > > it was on the to-do list. In any case, it is pretty clever software to
> > > say the least.
> > >
> > > On Monday 16 September 2002 05:11 pm, Stephen Bardsley spewed into the
> ether:
> > > > Greetings:
> > > >
> > > > I have been struggling with something and I hope
> > > > someone can set me straight.
> > > >
> > > > <%
> > > > I have a perl module, which contains a database
> > > > handle (dbh).
> > > >
> > > > I would like to use this module under Apache::ASP.
> > > > I would like to have users dynamically define a database
> > > > for the module to connect to. I can/will constrain
> > > > the lifetime of the module to that of an Apache::ASP
> > > > $Session.
> > > >
> > > > The trouble I am having is that I cannot maintain
> > > > the coherence of the dbh in the module. Sometimes
> > > > the dbh is defined and sometimes not. I have used
> > > > this module successfully in other Apache::ASP
> > > > applications, but the database has always been
> > > > statically defined to the module.
> > > >
> > > > Is there a way to allow the user to define the
> > > > database to the module?
> > > > %>
> > > >
> > > > Any suggestions will be greatly appreciated.
> > > >
> > > > Steve
> > > > _____________________
> > > > Stephen Bardsley
> > > > RLW Inc.
> > > > Malta, NY
> > > >
> > > > ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
> > > > For additional commands, e-mail: asp-help@perl.apache.org
> > >
> > > --
> > >
> > > -------------------------------------------------------------------------
> > >------- Check out http://www.Wizard.Org for great deals on Electronic
> > > Parts *NEW* Computer Parts & Accessories - Drives - LCD - Systems - Linux
> > > -------------------------------------------------------------------------
> > >------- ** Affordable Online Store w/Merchant Card Processing & Paypal **
> > > Write to us: sales@wizard.org -- Get your Store Online Today!
> > > -------------------------------------------------------------------------
> > >-------
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
> > For additional commands, e-mail: asp-help@perl.apache.org
>
> --
>
> --------------------------------------------------------------------------------
> Check out http://www.Wizard.Org for great deals on Electronic Parts
> *NEW* Computer Parts & Accessories - Drives - LCD - Systems - Linux
> --------------------------------------------------------------------------------
> ** Affordable Online Store w/Merchant Card Processing & Paypal **
> Write to us: sales@wizard.org -- Get your Store Online Today!
> --------------------------------------------------------------------------------
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: dynamic module
Posted by Brat Wizard <br...@naxs.com>.
> I want my variable to be valid and defined for the duration of a Session.
Okay, that's what the session object is for, as you appear to already know. ;)
> > example) is to use Apache::DBI. Apache::DBI will override the normal DBI
> I am using and have used Apache::DBI with good results. I'm sorry, I
> didn't mean to imply "on-the-fly" as from one script to the next. To be
> more precise I meant from one Session to the next.
Okay-- so if I'm understanding you correctly, connecting to the database each
time the script is executed (a la Script_OnStart) is okay, so what is the
problem with say storing the datasource parameters as session data and then
using it to reconstitute the handle each time? You can't cache the handle
itself, but you _can_ cache the name of the database connected to (and
whatever host/user info you need) as session scalars (or a hash-- or even
just store the actual DBI data source string itself if that's all you really
need). Then just use that information the next time around to re-connect to
the database.. Basically check to see if we've been connected before (ie. is
$..dbname defined, or whatever). If not, store it. When you're done, close
the connection and zap the data in the session variable (or abandon the
session altogether). Then go through the process all over again for the next
session..
You didn't say, but perhaps you are concerned about caching selected data from
a query and that's what the real bottom-line issue is?? (as in: why it would
be interesting/useful to be able to store a db handle in the session object
anyway...)
This is a trick I often use.. if the query is expensive (a full-text search or
something) and I don't want to have to rerun the query each time to get the
next chunk of data-- what I will do is run the query and ONLY select the
actual key(s) to the data itself in whatever order they're needed. (eg.
SELECT key_field FROM table WHERE blah blah ORDER BY blah blah) Then blast
the keys into a file-- several ways to do this quickly & effectively, the
easiest is to simply create a key array and use Storable to freeze it in a
file. Then you can just thaw it out later and use the list.
By using a key array, you can construct a query retrieving _only_ the items
needed for the specific page which is generally very fast (much much faster
usually) compared to running the query all over again (eg. SELECT
fields_i_need FROM table WHERE key=key1 or key=key2 or key=key3..etc) They
are already in the correct order so you don't need the overhead of an "order
by" clause.
When you're through, dump the key array whenever its convenient (or don't if
you don't care about disk space-- the frozen files are small, you can reap
them at your leisure).
If I'm displaying paged data, a simple rule I often employ is that either a
new sort order (clicking on a column header for instance) or retrieving page
zero will dump the cache & rerun the query (making a new key array). It
generally works quite well, and I've been very pleasantly surprised at how
small the frozen cache files are, even for large queries. And slurping up a
frozen array is pretty darned quick. If you hide all the mechanical bits
inside functions, pretty soon you forget how horrible a kludge this really is
and it almost begins to seem normal :) ;)
> > The next easiest thing to do is to figure out what database to connect to
> > and open it each time the script runs (the Script_OnStart() function is a
>
> This is kind of what I am doing now, and can't quite get things working.
> It seems it may actually be an issue with variable scoping. If I scope
> my module's instance variable in the Script_OnStart things seem to work.
> That is, I create the instance in Script_OnStart. If I create the
> instance in one of global.asa's sub's then it does not seem to work
> reliably. Bear in mind I am using global variables in global.asa
> by way of "use vars qw( $var2 $var2 $etc );". If this is incorrect
> or a better way exists, I'm all ears. Thanks again for your time.
Hmm- interesting. I do it in subs all the time with no problems whatsoever. I
declare the global variable the same way you do, "use vars qw( $db ... blah
blah);" at the top of my global.asa file (and again in EVERY package file
that is not a separate module-- not a separate namespace-- I break a lot of
my code up into sub-files to keep it more manageable). The scope should be
global. Might you have some my variable someplace that's stomping on the
global version??
I have a Db.pm module that I wrote that basically encapsulates most of the DBI
stuff I use-- so keep that in mind in the short example below-- it isn't
exactly what you're used to but it will be similar enough. In one of my
global.asa files, the flow goes something like this:
package Apache::ASP::STORES;
use vars qw{ $db ... [more vars] };
use lib Apache->request->dir_config('BaseDir')."/lib";
use Apache::ASP;
use Db;
[more use statements]
sub Script_OnStart {
[..do stuff]
connectToDB();
[.. do more stuff.. ]
}
sub connectToDB {
my $dbname = <my dbname>; ## actually declared elsewhere
my $dbhost = <my host>; ## for me, but you get the idea
return if ($db ne undef); ## got a handle thanks, don't need another
$db = new Db;
$db->Connect($dbname, $dbhost);
return $db;
}
In this case, the $db handle that gets returned is of my own "db" style that I
mentioned. But it only wraps around the usual dbh handle and is mostly
exposed except for wrapping commonly used constructs to make slapping
together code quicker, easier, and a bit more mindless. Its pretty easy
actually, even my cat could do it... (as it happens, I walked into the
computer room one day and there he was sitting building a database cataloging
north american migratory birds and cross-referencing them by recipe... but
that's another story altogether ;)
Hope this helps-
John Whitten
brat@naxs.com
Wizard.Org, Inc.
>
> > The best way (but not necessarily the easiest) is to use some sort of
> > middleware such as SQLrelay or something similar that will sit between
> > your perl application and the database, maintain open connections and
> > drop or establish new connections as demanded. SQLrelay is a neat thing
> > but it is a pain-in-the-ass (IMO) to install and configure. (I should
> > also point out that my experience with it is some 6+months old so a newer
> > version which may address some of these issues may be available?)
> > SQLrelay works with just about any database DBI can work with, and in
> > addition can work across servers, and I *think* (perhaps it was a planned
> > feature, in any case I never used it myself) it had auto-failover support
> > in case one server didn't answer up-- won't swear to that though- perhaps
> > it was on the to-do list. In any case, it is pretty clever software to
> > say the least.
> >
> > On Monday 16 September 2002 05:11 pm, Stephen Bardsley spewed into the
ether:
> > > Greetings:
> > >
> > > I have been struggling with something and I hope
> > > someone can set me straight.
> > >
> > > <%
> > > I have a perl module, which contains a database
> > > handle (dbh).
> > >
> > > I would like to use this module under Apache::ASP.
> > > I would like to have users dynamically define a database
> > > for the module to connect to. I can/will constrain
> > > the lifetime of the module to that of an Apache::ASP
> > > $Session.
> > >
> > > The trouble I am having is that I cannot maintain
> > > the coherence of the dbh in the module. Sometimes
> > > the dbh is defined and sometimes not. I have used
> > > this module successfully in other Apache::ASP
> > > applications, but the database has always been
> > > statically defined to the module.
> > >
> > > Is there a way to allow the user to define the
> > > database to the module?
> > > %>
> > >
> > > Any suggestions will be greatly appreciated.
> > >
> > > Steve
> > > _____________________
> > > Stephen Bardsley
> > > RLW Inc.
> > > Malta, NY
> > >
> > > ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
> > > For additional commands, e-mail: asp-help@perl.apache.org
> >
> > --
> >
> > -------------------------------------------------------------------------
> >------- Check out http://www.Wizard.Org for great deals on Electronic
> > Parts *NEW* Computer Parts & Accessories - Drives - LCD - Systems - Linux
> > -------------------------------------------------------------------------
> >------- ** Affordable Online Store w/Merchant Card Processing & Paypal **
> > Write to us: sales@wizard.org -- Get your Store Online Today!
> > -------------------------------------------------------------------------
> >-------
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
> For additional commands, e-mail: asp-help@perl.apache.org
--
--------------------------------------------------------------------------------
Check out http://www.Wizard.Org for great deals on Electronic Parts
*NEW* Computer Parts & Accessories - Drives - LCD - Systems - Linux
--------------------------------------------------------------------------------
** Affordable Online Store w/Merchant Card Processing & Paypal **
Write to us: sales@wizard.org -- Get your Store Online Today!
--------------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
RE: dynamic module
Posted by Stephen Bardsley <sb...@rlwinc.com>.
Brat Wizard:
I greatly appreciate the input. I have some responses
inline below. Thanks again.
Steve
> -----Original Message-----
> From: Brat Wizard [mailto:brat@naxs.com]
> Sent: Monday, September 16, 2002 6:40 PM
>
> Hi there-
>
> I do stuff like this all the time-- You cannot store a DBI database handle
> (dbh) in a session variable and expect it to be there when you get back. If
> it has worked for you in the past, you were simply lucky (or using
> Apache::DBI and not realizing it was cached.. see below). Another thing that
> session variables have problems with is being used in a complex way. You can
> _read_ them anyway you like. If you _modify_ them though, you need to update
> the _entire_ structure in one shot or risk squirrely problems. Josh points
> this out (I think it is in the FAQ section) on the ASP home page. I normally
> define a global variable called $db (eg. use vars $db;) and manipulate it
> that way.
>
I understand the problem, and do not use the $Session object in that way.
What I meant by $Session was more in the time domain than state domain.
I want my variable to be valid and defined for the duration of a Session.
>
> As far as persistance goes-- that's a mixed bag.. You can do one of several
> things-- the first (and probably NOT what you want given your example) is to
> use Apache::DBI. Apache::DBI will override the normal DBI open & close
> statements and will open a single dbh (PER Apache CHILD process) and will
> maintain that connection for the entire lifespan of that child process. For
> some applications that open a single, unchanging connection to a database,
> this is the behavior you might want. Apache::DBI then returns its own
> privately-kept copy of the db handle anytime perl attempts to connect to the
> database. Likewise it simply returns whenever a close is called-- ignores the
> close altogether.
>
> But, if you want to be able to change what database the handle is connected to
> "on-the-fly", then this approach is not for you.
I am using and have used Apache::DBI with good results. I'm sorry, I didn't
mean to imply "on-the-fly" as from one script to the next. To be more
precise I meant from one Session to the next.
>
> The next easiest thing to do is to figure out what database to connect to and
> open it each time the script runs (the Script_OnStart() function is a good
> place to do this). There is a small drag on connecting each time. For
> Postgres, MySql, and probably others-- it isn't so bad but your mileage may
> vary. This provides the ultimate in flexibility at the cost of having to
> reestablish the connection each time you connect.
>
This is kind of what I am doing now, and can't quite get things working.
It seems it may actually be an issue with variable scoping. If I scope
my module's instance variable in the Script_OnStart things seem to work.
That is, I create the instance in Script_OnStart. If I create the
instance in one of global.asa's sub's then it does not seem to work
reliably. Bear in mind I am using global variables in global.asa
by way of "use vars qw( $var2 $var2 $etc );". If this is incorrect
or a better way exists, I'm all ears. Thanks again for your time.
>
> The best way (but not necessarily the easiest) is to use some sort of
> middleware such as SQLrelay or something similar that will sit between your
> perl application and the database, maintain open connections and drop or
> establish new connections as demanded. SQLrelay is a neat thing but it is a
> pain-in-the-ass (IMO) to install and configure. (I should also point out that
> my experience with it is some 6+months old so a newer version which may
> address some of these issues may be available?) SQLrelay works with just
> about any database DBI can work with, and in addition can work across
> servers, and I *think* (perhaps it was a planned feature, in any case I never
> used it myself) it had auto-failover support in case one server didn't answer
> up-- won't swear to that though- perhaps it was on the to-do list. In any
> case, it is pretty clever software to say the least.
>
>
>
>
> On Monday 16 September 2002 05:11 pm, Stephen Bardsley spewed into the ether:
> > Greetings:
> >
> > I have been struggling with something and I hope
> > someone can set me straight.
> >
> > <%
> > I have a perl module, which contains a database
> > handle (dbh).
> >
> > I would like to use this module under Apache::ASP.
> > I would like to have users dynamically define a database
> > for the module to connect to. I can/will constrain
> > the lifetime of the module to that of an Apache::ASP
> > $Session.
> >
> > The trouble I am having is that I cannot maintain
> > the coherence of the dbh in the module. Sometimes
> > the dbh is defined and sometimes not. I have used
> > this module successfully in other Apache::ASP
> > applications, but the database has always been
> > statically defined to the module.
> >
> > Is there a way to allow the user to define the
> > database to the module?
> > %>
> >
> > Any suggestions will be greatly appreciated.
> >
> > Steve
> > _____________________
> > Stephen Bardsley
> > RLW Inc.
> > Malta, NY
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
> > For additional commands, e-mail: asp-help@perl.apache.org
>
> --
>
> --------------------------------------------------------------------------------
> Check out http://www.Wizard.Org for great deals on Electronic Parts
> *NEW* Computer Parts & Accessories - Drives - LCD - Systems - Linux
> --------------------------------------------------------------------------------
> ** Affordable Online Store w/Merchant Card Processing & Paypal **
> Write to us: sales@wizard.org -- Get your Store Online Today!
> --------------------------------------------------------------------------------
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org
Re: dynamic module
Posted by Brat Wizard <br...@naxs.com>.
Hi there-
I do stuff like this all the time-- You cannot store a DBI database handle
(dbh) in a session variable and expect it to be there when you get back. If
it has worked for you in the past, you were simply lucky (or using
Apache::DBI and not realizing it was cached.. see below). Another thing that
session variables have problems with is being used in a complex way. You can
_read_ them anyway you like. If you _modify_ them though, you need to update
the _entire_ structure in one shot or risk squirrely problems. Josh points
this out (I think it is in the FAQ section) on the ASP home page. I normally
define a global variable called $db (eg. use vars $db;) and manipulate it
that way.
As far as persistance goes-- that's a mixed bag.. You can do one of several
things-- the first (and probably NOT what you want given your example) is to
use Apache::DBI. Apache::DBI will override the normal DBI open & close
statements and will open a single dbh (PER Apache CHILD process) and will
maintain that connection for the entire lifespan of that child process. For
some applications that open a single, unchanging connection to a database,
this is the behavior you might want. Apache::DBI then returns its own
privately-kept copy of the db handle anytime perl attempts to connect to the
database. Likewise it simply returns whenever a close is called-- ignores the
close altogether.
But, if you want to be able to change what database the handle is connected to
"on-the-fly", then this approach is not for you.
The next easiest thing to do is to figure out what database to connect to and
open it each time the script runs (the Script_OnStart() function is a good
place to do this). There is a small drag on connecting each time. For
Postgres, MySql, and probably others-- it isn't so bad but your mileage may
vary. This provides the ultimate in flexibility at the cost of having to
reestablish the connection each time you connect.
The best way (but not necessarily the easiest) is to use some sort of
middleware such as SQLrelay or something similar that will sit between your
perl application and the database, maintain open connections and drop or
establish new connections as demanded. SQLrelay is a neat thing but it is a
pain-in-the-ass (IMO) to install and configure. (I should also point out that
my experience with it is some 6+months old so a newer version which may
address some of these issues may be available?) SQLrelay works with just
about any database DBI can work with, and in addition can work across
servers, and I *think* (perhaps it was a planned feature, in any case I never
used it myself) it had auto-failover support in case one server didn't answer
up-- won't swear to that though- perhaps it was on the to-do list. In any
case, it is pretty clever software to say the least.
On Monday 16 September 2002 05:11 pm, Stephen Bardsley spewed into the ether:
> Greetings:
>
> I have been struggling with something and I hope
> someone can set me straight.
>
> <%
> I have a perl module, which contains a database
> handle (dbh).
>
> I would like to use this module under Apache::ASP.
> I would like to have users dynamically define a database
> for the module to connect to. I can/will constrain
> the lifetime of the module to that of an Apache::ASP
> $Session.
>
> The trouble I am having is that I cannot maintain
> the coherence of the dbh in the module. Sometimes
> the dbh is defined and sometimes not. I have used
> this module successfully in other Apache::ASP
> applications, but the database has always been
> statically defined to the module.
>
> Is there a way to allow the user to define the
> database to the module?
> %>
>
> Any suggestions will be greatly appreciated.
>
> Steve
> _____________________
> Stephen Bardsley
> RLW Inc.
> Malta, NY
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
> For additional commands, e-mail: asp-help@perl.apache.org
--
--------------------------------------------------------------------------------
Check out http://www.Wizard.Org for great deals on Electronic Parts
*NEW* Computer Parts & Accessories - Drives - LCD - Systems - Linux
--------------------------------------------------------------------------------
** Affordable Online Store w/Merchant Card Processing & Paypal **
Write to us: sales@wizard.org -- Get your Store Online Today!
--------------------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: asp-unsubscribe@perl.apache.org
For additional commands, e-mail: asp-help@perl.apache.org