Just wanted to show you how things have been shaping up thus far as I
work to fill in the blanks (in both my knowledge of how this is all
going to fit together, and in the missing methods I'll need to get the
jobs done)
http://www.webdragon.net/miscel/Subscriber.pm
http://www.webdragon.net/mis
On Jul 19, Scott R. Godin said:
I'd LIKE to be able to (I think) inherit from Subscriber::DB somehow for a
Subscriber::DB::CSV such that I can take the filtered request and
retrieve/output CSV-formatted records from the database..
I've already produced the code to do so in another command-li
On Jul 18, Scott R. Godin said:
So, there will be instances where only one user will be handled, and instances
where we'll be sifting through all the users for specific data (email,
snailmail, birthday, anniversary)
I'm leaning towards (per your comments above) the Subscriber::DB holding the
Jeff,
Thanks again for your time and assistance thus far with helping me to
visualise this. :)
Another thought has occurred to me as well, with regards to
Subscriber::DB :
one of the client requests is to be able to extract the database, or
portions of the database to a CSV style format.
One other thing that's bugging me about this is how to provide the
config data to the scripts at runtime in a web environment.
If this were a one-time script it would be simple to hard-code them in,
but we expect to be able to re-use the package for multiple client
environments.
The constrai
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 da
te
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 yo
Jeff 'japhy' Pinyan wrote:
On Jul 13, Scott R. Godin said:
The original object itself is at
http://www.webdragon.net/miscel/Subscriber.pm
[snip]
Additionally uploaded my skeleton starting ideas on Subscriber::DB at
http://www.webdragon.net/miscel/DB.pm
All Subscriber::DB objects would shar
Jeff 'japhy' Pinyan wrote:
On Jul 13, Scott R. Godin said:
The first thing you need to do is figure out the mapping from the old
methods to the new methods.
I'm not quite certain what you're getting at, here. You mean, which
methods will get re-mapped to do things slightly differently for t
On Jul 13, Scott R. Godin said:
The first thing you need to do is figure out the mapping from the old
methods to the new methods.
I'm not quite certain what you're getting at, here. You mean, which methods
will get re-mapped to do things slightly differently for the DB version?
Right. What
Jeff 'japhy' Pinyan wrote:
On Jul 13, Scott R. Godin said:
The original object itself is at
http://www.webdragon.net/miscel/Subscriber.pm
Now updated some, as mentioned below :)
(the Subscriber::DB object will need $database, $username, $password,
a DBI $dbh handle, and possibly a $hostname
On Jul 13, Jeff 'japhy' Pinyan said:
# Subscriber::DB::get_greeting
sub get_greeting {
my ($self) = @_;
my $id = $self->{_id};
$greeting_sql->bind_columns(
\$self->{_salutation},
\$self->{_firstname},
\$self->{_lastname},
);
$greeting_sql->execute($id);
It turn
On Jul 13, Jeff 'japhy' Pinyan said:
Or you could have a set() method:
sub set {
my $self = shift;
while (@_) {
my ($field, $value) = @_;
That should be:
my ($field, $value) = (shift, shift);
if (exists $self->{$field}) { $self->{$field} = $value }
else { die
On Jul 13, Scott R. Godin said:
The original object itself is at http://www.webdragon.net/miscel/Subscriber.pm
(the Subscriber::DB object will need $database, $username, $password, a DBI
$dbh handle, and possibly a $hostname as well, in addition to the data stored
in the Subscriber object, th
This might be better suited for the DBI list, but primarily I'm
interested in learning more about the things necessary to enable me to
take an existing module's object and make its data persistent (via a
mysql database)
I've been giving thought to inheriting from the main module. Or not. in
n
15 matches
Mail list logo
