[Dbix-class] CDBI Compatability Issue: Iterators

Christopher H. Laco claco at chrislaco.com
Fri Aug 19 21:43:54 CEST 2005

Matt S Trout wrote:
> On Fri, Aug 19, 2005 at 10:46:41AM -0400, Christopher H. Laco wrote:
>>That also worked but brought up another problem.
>>DBIx::Class::Resultset->next calls
>>DBIx::Class::Row->_row_to_object($self->{cols}, \@row)
>>DBIx::Class::Row->_row_to_object calls
>>$class->new(\%vals) on the child object class to be created, which in my 
>>case has it's own custom ->new() method.
> The thing being, ->create calls ->new so unless your ->new is compatible
> you're still going to have problems.
>>This is different from Class::DBI::Iterator; whos next method calls 
> Yep. I should really add a "sub construct { shift->new(@_); }" to emulate
> this.
>>So, how do we fix this? can _row_to_object have and extra paramater 
>>specifying the constructore method?
> Providing a single constructor method with the standard name for said
> is critical to allow people to override/tweak/whatever object construction
> in a standard way. Your problem as I see it is that Class::DBI behaves
> non-standardly in terms of object construction and you've mistakenly assumed
> whatever other libraries you use will make the same design error :)

I'll freely admit that I may be doing something strange with respect to 
new vs construct. With that said, and with a deign error in CDBI or not, 
the CDBICompat layer needs to be just that: compatable.

Even if I didn't have a new() in my child class, CDBIs iterator still 
calls construct; and thus the CDBICompat layer should do the same IMHO. 
Otherwise, what's the point of a compatibility layer if it isn't 
compatable to whatever bad choice its target may have made?

If the CDBI docs didn't mention or allow subclassing the Iterator class, 
or if it didn't declere construct() as a publicly comsumable method, I'd 
agree this would be my problem alone. But it does allow for both of 
those things and so should CDBICompat....somehow.

That's not to say some form of Handel hacking can't work around it either.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 3178 bytes
Desc: S/MIME Cryptographic Signature
Url : http://lists.rawmode.org/pipermail/dbix-class/attachments/20050819/71476569/smime.bin

More information about the Dbix-class mailing list