in reply to Object Oriented Pattern help

*Question 1-> There has to be a more efficient way to 
*store the queries because I am defining the queries 
*each time the method is called... but where should 
*they be stored? 

Create an .PM file called Queries.pm (or some such name as that.) In that file you start off with:

package Queries; use DBI; use strict; #we really don't care about this as we are not #going to instantiate a Queries object. Just its #children sub new { my $proto=shift; my $class=ref($proto) || $proto; my $self={}; bless $self,$class; # We'll just put this here for clarity $self -> init(); return $self; } sub init { my $self=shift; #modify this to suit your situation my $self->{dbh}=DBI->connect('DBI:mysql',"username" ,"password" ); } sub execute { my $self=shift; my @parms=@_; return unless $self->{dbh}; return unless $self->{sql}; $self->{sth}=$self->{dbh}->prepare($self->{sql}); } sub fetchrow_hashref { my $self=shift; return unless $self->{sth}; return $self->{sth}->fetchrow_hashref; }
8<snip!8<

Now that you have the base class you can add more classes to the same .pm file as follows:

package loadusertable; use Queries; use strict; use vars qw( @ISA ); @ISA=qw(Queries); sub new { my $proto=shift; my $class=ref($proto) || $proto; my $self={}; bless $self,$class; $self->init; # we get that from the base class $self->{sql}="select * from users where id=?"; return $self; }

Now we have a class that when we instatiate it it connects to the database and can be used as follows:

use Queries; use strict; my $q=new loadusertable; $q->execute(15); my $row=$q->fetchrow_hashref;

There is more that can be done with this. This was just a quick "something" I threw together to answer your question.

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Peter L. Berghold --- Peter@Berghold.Net "Those who fail to learn from history are condemned to repeat it."

Replies are listed 'Best First'.
Re: Re: Object Oriented Pattern help
by arturo (Vicar) on May 14, 2001 at 01:08 UTC

    I have never, ever benchmarked this, but prepare_cached1 should get you increased performance, especially if you're using your queries a lot.

    In other words, what repson said =)

    1"the statement handle returned will be stored in a hash associated with the `$dbh'. If another call is made to `prepare_cached' with the same `$statement' and `%attr' values, then the corresponding cached `$sth' will be returned without contacting the database server" from the DBI documentation.

    perl -e 'print "How sweet does a rose smell? "; chomp $n = <STDIN>; $r +ose = "smells sweet to degree $n"; *other_name = *rose; print "$other +_name\n"'

      As I said in my write up there is a lot more that can be done with the code that I presented. For instance, how about having just one DBH for the module as a whole? This way the first instantiation of an object declared in the .PM would make a connection and that connection would be used until nobody cared any more.

      I am not always convinced that fetchrow_hashref is all that efficient. In fact in the DBI man page it says that it isn't.

      One cat. Many ways to skin it and only that cat objects to how it is skinned...

      ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Peter L. Berghold --- Peter@Berghold.Net "Those who fail to learn from history are condemned to repeat it."