You are viewing a plain text version of this content. The canonical link for it is here.
Posted to embperl@perl.apache.org by Kee Hinckley <na...@somewhere.com> on 2003/11/19 01:54:55 UTC
Subclassing DBIx::Recordset
Has anyone tried subclassing DBIx::Recordset? I've been playing with
it and there are a couple issues that I've found.
1. There are a number of places in the code where the current object
is compared to DBIx::Recordset with an 'eq' rather than using an
'isa'. That's pretty easy to fix.
2. There are a number of places where the hash and array helper
classes are called. To do what I want I would need to subclass them
as well. Which means that I'd probably have to add functionality to
allow the DBIx::Recordset class and subclasses to store the names of
the helper classes they want to use.
At present I'm inclined towards using encapsulation instead, and
making use of AUTOLOAD to redirect any unknown functions to the
internal DBIx::Recordset object, but I wondered if anyone had any
thoughts on the matter.
--
Kee Hinckley
http://www.messagefire.com/ Next Generation Spam Defense
http://commons.somewhere.com/buzz/ Writings on Technology and Society
I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Subclassing DBIx::Recordset
Posted by Gerald Richter <ri...@ecos.de>.
>
> Well, you convinced me to give it a try, and it appears to now be
> working. I want to test it a few more days and then I'll put out the
> patches. I made the following changes.
>
That sounds really great!
> And the other
> option is the ability to trigger function callbacks when certain
> fields are modified.
>
You can use the filters that are already exits in DBIx::Recordset for that
purpose.
Gerald
--------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
IT-Securitylösungen * dynamische Webapplikationen * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 939-122
WWW: http://www.ecos.de/ Fax: +49 6133 939-333
--------------------------------------------------------------
|
| ECOS BB-5000 Firewall- und IT-Security Appliance: www.bb-5000.info
|
+-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Subclassing DBIx::Recordset
Posted by Kee Hinckley <na...@somewhere.com>.
At 8:15 AM +0100 11/19/03, Gerald Richter wrote:
>I would prefer to extent DBIx::Recordset, so it could be easily subclassed.
>
>Since Terrence is now working on DBIx::Recordset, we hopefully will have a
>new release with patches of the last year incoorporated soon.
Well, you convinced me to give it a try, and it appears to now be
working. I want to test it a few more days and then I'll put out the
patches. I made the following changes.
- Most of the places where there were calls to DBIx::Recordset::Setup
were easily replaced with $class or $self -> Setup. One instance
(searching on links) had to be replaced with
ref($self->{'*Recordset'})->Search(...).
- I added three new methods to DBIx:Recordset; RowClass, HashClass
and CurrRowClass. (Someday I need to figure out what the distinction
is between CurrRowClass and RowClass.) In DBIx::Recordset these
return 'DBIx::Recordset::Row', 'DBIx::Recordset::Hash', and
'DBIx::Recordset::CurrRow' respectively. Subclasses of
DBIx::Recordset can change them if desired, so long as the return
value references a subclass of the the base DBIx::Recordset::*
classes.
- I changed any direct class comparisons to ISA comparisons.
So far it seems to work, although I haven't tried subclassing the
helper classes yet. I did migrate my encapsulation class
(DBIx::Objectset) to a subclass of DBIx::Recordset.
One of the interesting things my subclass does is attempt to
determine the appropriate class based on the table name. In other
words, if I have a subclass of DBIx::Objectset called MF::Set and I
create a new instance of MF::Set using {!Table => "foo"}, then the
Setup method will look for (in memory, and via "require")
MF::Set::Foo or MF::Foo before defaulting to a new instance of
MF::Set. This allows you to create domain-specific behavior for
certain tables. For instance, you could override "Insert" and have
it check to see if all the arguments that you require have been
specified. Or you could cascade an Update so that it updated related
tables at the same time. With that model you can do the following
kinds of things.
*account = MF::Set->Setup({ '!Table' => 'account' });
# returns an MF::Set::Account object
*user = $account{-user};
# returns an MF::Set::User object
*article = MF::Set::Article->Setup();
# the default Setup method will set the !Table value
(None of those examples set the database info because DBIx::Objectset
specifies the connect string, username, password and related values
as methods that can be overridden by subclasses to provide default
values.)
My database relationships were getting too complex, especially where
MySQL doesn't do any cross-table consistency checking, and the
procedural code was just getting too messy, with different
dependencies scattered around. This allows me to encapsulate all of
the table-specific knowledge in a single object that is tied to that
table.
Still left to migrate to the new subclass, or possibly into Recordset
itself are two other features. "Safe" mode throws an error if you
try to write or read a fieldname that doesn't exist. And the other
option is the ability to trigger function callbacks when certain
fields are modified.
--
Kee Hinckley
http://www.messagefire.com/ Next Generation Spam Defense
http://commons.somewhere.com/buzz/ Writings on Technology and Society
I'm not sure which upsets me more: that people are so unwilling to accept
responsibility for their own actions, or that they are so eager to regulate
everyone else's.
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org
Re: Subclassing DBIx::Recordset
Posted by Gerald Richter <ri...@ecos.de>.
Kee Hinckley wrote:
> Has anyone tried subclassing DBIx::Recordset? I've been playing with
> it and there are a couple issues that I've found.
>
I didn't have tried it so far
> 1. There are a number of places in the code where the current object
> is compared to DBIx::Recordset with an 'eq' rather than using an
> 'isa'. That's pretty easy to fix.
This was a perfomance hack from times where webserver were really slow
compared to nowadays. This should be really fixed.
> 2. There are a number of places where the hash and array helper
> classes are called. To do what I want I would need to subclass them
> as well. Which means that I'd probably have to add functionality to
> allow the DBIx::Recordset class and subclasses to store the names of
> the helper classes they want to use.
>
Yes, this would be a good idea.
> At present I'm inclined towards using encapsulation instead, and
> making use of AUTOLOAD to redirect any unknown functions to the
> internal DBIx::Recordset object, but I wondered if anyone had any
> thoughts on the matter.
I would prefer to extent DBIx::Recordset, so it could be easily subclassed.
Since Terrence is now working on DBIx::Recordset, we hopefully will have a
new release with patches of the last year incoorporated soon.
Gerald
--------------------------------------------------------------
Gerald Richter ecos electronic communication services gmbh
IT-Securitylösungen * dynamische Webapplikationen * Consulting
Post: Tulpenstrasse 5 D-55276 Dienheim b. Mainz
E-Mail: richter@ecos.de Voice: +49 6133 939-122
WWW: http://www.ecos.de/ Fax: +49 6133 939-333
--------------------------------------------------------------
|
| ECOS BB-5000 Firewall- und IT-Security Appliance: www.bb-5000.info
|
+-------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: embperl-unsubscribe@perl.apache.org
For additional commands, e-mail: embperl-help@perl.apache.org