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
Jeff 'japhy' Pinyan wrote:
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 exa
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 thi
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
14 matches
Mail list logo
