On Jul 13, Scott R. Godin said:
http://www.webdragon.net/miscel/DB.pm
I'll check it out.
All Subscriber::DB objects would share the DBI object -- there's no need for
a billion database handles.
ok, so possibly one should do it differently than I have, in my example.
Well, look at it this way: either the Subscriber::DB object holds the
database, or it holds a subscriber. Choose.
If it holds the database, then it needs a method to lookup, create, and
return a Subscriber object from the database.
If it holds the subscriber, it needs to CALL the database to populate
itself.
But what I had thought of doing would be to populate the object via the
database and fill it entire, thus being able to call any of the Subscriber
methods on it without generating multiple calls to the database for each one.
Ah, so by "object persistence" you mean that you want to create the
objects from the state they had in the database, and then when you're done
with them, save them back to the database? That seems reasonable, if
you're not going to have multiple processes accessing and changing this
information.
The way I envisioned it was very similar to a tie() mechanism. Every
access or setting of a value triggers a database action. Your method is
certainly less of a strain on the database.
One problem-space I'm still trying to wrap into the picture is the need to be
able to grab data from the database based on different criterion.. for
example "everyone who has requested info by e-mail only", or the opposite --
people who want their info snail-mailed to them.
That's just SQL.
SELECT *
FROM subscribers
WHERE email IS NOT NULL
Something like that would get all the records that had email addresses
filled in.
Here is my new take on what you want Subscriber::DB to do:
1. you create a connection to the database
2. you get all the records from the database (in the form of Subscriber
objects) which match a certain criteria
3. you fiddle with them
4. if you make changes, they get reflected in database when you're done
Does that sound appropriate?
use Subscriber::DB;
my $email_dbh = Subscriber::DB->new; # makes a new connection
$email_dbh->filter('email IS NOT NULL'); # sets up criteria
my @email_subs = $email_dbh->subscribers; # gets matches
my $snail_dbh = Subscriber::DB->new; # makes a new connection
$snail_dbh->filter('email IS NULL'); # sets up criteria
my @snail_subs = $email_dbh->subscribers; # gets matches
Is that what you envision? The storage of the Subscriber objects
somewhere in the Subscriber::DB object? I would change it to needing only
ONE S::DB object:
my $dbh = Subscriber::DB->new;
my @email_subs = $dbh->filter('email IS NOT NULL'); # runs the search
my @snail_subs = $dbh->filter('email IS NULL'); # ditto
The other idea I have is to return not Subscriber objects, but objects
that inherit from Subscriber, for this reason: you can override their
DESTROY handler to update the database when they die!
package Subscriber::DB;
sub filter {
my ($dbh, @how) = @_;
my @results = ...; # DBI magic here
my @obj;
for my $rec (@results) {
# the object needs to know the DBI handle it came from
my $s = Subscriber::Updater->new($dbh, $rec);
push @obj, $s;
}
return @obj;
}
package Subscriber::Updater;
use base 'Subscriber';
sub new {
my ($class, $dbh, $data) = @_;
# fill it in...
}
DESTROY {
my ($self) = @_;
my $db = $self->{_dbh}; # or however you'd prefer
# do some updating of the DB based on the contents of the object
}
How's that sound?
--
Jeff "japhy" Pinyan % How can we ever be the sold short or
RPI Acacia Brother #734 % the cheated, we who for every service
http://japhy.perlmonk.org/ % have long ago been overpaid?
http://www.perlmonks.org/ % -- Meister Eckhart
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
