RE: Is there a point in using the request object for db connections whenusing Apache::DBI?

[Andrew O'Brien <an...@oriel.com.au>]

> From: John P. Gibbons [mailto:john@dashing.com] 
> Subject: Is there a point in using the request object for db 
> connections when using Apache::DBI?

Hi John,

(note - I use HTML::Embperl extensively and exclusively so my ideas
 may be slanted somewhat)

> I was reading this article: 
> http://www.perl.com/pub/a/2001/03/embperl.html and of course this 
> mailing list and have seen reference to people using the $req 
> object to 
> have one database connection.
> 
> On my sites I did not do it that way. I use Apache::DBI to handle the 
> DBI connection issue and do a separate connects  in my 
> base.html and in 
> all other referenced Embperl files/code. Apache::DBI of course makes 
> sure we really only have one connection per httpd, as you all know.

I've generally found that for large application sites that involve a
large amount of common backend code with (possibly) many database
handles then the best way of dealing with it is to do as you have done
and let Apache::DBI take care of caching the (possibly) large number
of different database handles that are used throughout the perl
modules that generally fall out of such a setup. *Gasp*

Most of the modules that I write for such applications inherit from a
common base database class (think home grown Class::DBI) and have
intrinsic class-based handle sharing but its all the same idea.

None of the website code cares about database details whatsoever.
Abstraction and website code simplification are your friends. Well,
abstraction and efficient caching and code simplification. And ... :)

> I was wondering if there is any benefit or reason to use the request 
> object method in my scenario? I'm looking at ways to optimize 
> my code as 
> it has grown dramatically and this has been in the back of my 
> mind for 
> awhile. I remember reading something that in order to give db 
> access to 
> an include embperl file with only subroutines you'd have to use that 
> method. But I can't recall now. I was also thinking that 
> there are cases 
> when I call .epl files directly and do not want them wrapped in 
> base.html. If I were to use the request object method then I would 
> either be out of luck or would have to code around it somehow.

Using perl modules for the majority of data manipulation sidesteps this
kind of issue neatly.

> What's more, is this the appropriate place for these sorts of 
> questions?

AFAIK

> I have an interest in discussing Embperl with other 
> developers who are 
> actually making websites and learning about how they did things, etc. 

I certainly have a set of approaches that I've found useful over the
years that I'd be happy to share.

> All I usually see on the list are tech support related 
> discussions. If 
> this is the wrong place for that, is there another list or site that 
> might be better? If not would it be at all interesting if someone 
> started one? I'd be open minded to that as a side project. I already 
> have a complete content management system and community (with forums, 
> user profiles, etc) all written in Embperl. So I could do it 
> in short order.

There was talk of setting up something like this not-quite-so-recently.
Gerald has adapted several posts into HOWTO's and the like but I can't
recall a specific site.

I'd certainly be interested.

Cheers,

Andrew

---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org

Re: Is there a point in using the request object for db connections whenusing Apache::DBI?

[John Gibbons <jo...@dashing.com>]

>Most of the modules that I write for such applications inherit from a
>common base database class (think home grown Class::DBI) and have
>intrinsic class-based handle sharing but its all the same idea.
>
>None of the website code cares about database details whatsoever.
>Abstraction and website code simplification are your friends. Well,
>abstraction and efficient caching and code simplification. And ... :)
>
>  
>

Hi Andrew,

Yeah something like that does seem to make sense. However when you say 
you've abstracted everything from the website code, how abstracted do 
you mean? For example what I do now is do a connect in each file (with 
variables from a config file for username, db, etc) and then use the DBI 
interface to run a sql query or insert data, etc. How would your method 
be better? Are you removing all sql statements from your code and just 
making calls to the module which returns data? Is it just neater that way?

Have a look at a couple of my sites, http://catstevens.com/ and 
http://robbiefulks.com/ . They are both running the same software, in 
fact the code is in a main directory on the server and symlinked into 
each sites document root. This way I'm forced to make my code portable 
or I'll break things! :-) See the forums and community features (feel 
free to sign up for instance).

Anyhow there are so many database calls and things going on that are 
unique to each section of the site that I'm not sure how much 
abstraction would be possible. That is depending on what you mean by that.

I'm in the middle of a major upgrade right now that is focused on 
XHTML/CSS standards compliance and I figured now is the time to atone 
for some sins since I'm already ripping the code apart. :-)

>There was talk of setting up something like this not-quite-so-recently.
>Gerald has adapted several posts into HOWTO's and the like but I can't
>recall a specific site.
>
>I'd certainly be interested.
>  
>
As I said before I could easily do something like this, and have an 
interest in it. But I wouldn't want to step on anyones toes. If someone 
else had plans to do it then that's great. But if not I'd be happy to. I 
would just like a site like that to exist, regardless of who does it. 
Gerald, any thoughts?

Cheers,
John


---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org