[CDBI] Make CDBI go fast

Michael G Schwern schwern at gmail.com
Thu Feb 15 16:48:55 GMT 2007


Dan Rowles wrote:
>> * Inflate columns into objects on demand.
>>
>> CDBI inflates columns as soon as they are fleshed out.   If the
>> inflated column is never accessed then its a plain waste.  If a class
>> has relationships it can result in a cascade of inflations and object
>> loads.
> 
> If I remember correctly, when inflating columns which are part of a
> "has_a" relationship, Class::DBI just calls the _simple_bless() method,
> which won't go to the database at all. So this is probably less of a
> problem than you think. I don't think you can get cascading database
> loads this way.....

Yes, it seems you're right.  It might be due to the special foreign key constraint checking code they have here.  In short... MySQL lacks a way to create or break circular relationships without turning off constraint checking.  That's ok, but the problem is when it comes back on at the end of the transaction it doesn't check that what that transaction did is ok!  Guh.  So they've implemented constraint checking in Perl using CDBI.

I'd love to throw all that out the window.

Or maybe its not really cascade-inflating at all and I didn't check right.  I'll look again.

As for non-relationship inflates, it becomes an issue when you have, say, dates inflating to DateTime objects and currency inflating to a BigFloat-based Currency object.  Those objects are pretty cheap to make but it becomes a noticeable overhead when you're building a huge report (say, a hundred thousand line CSV) and CDBI inflates hundreds of thousands of times only to throw it away without using it.

Its gotten to the point that they've created a proxy object around DateTime.  CDBI inflates to the cheap proxy object and the proxy object only instantiates the real DateTime object on use.  This helps but it would be even cheaper if CDBI didn't inflate at all.



More information about the ClassDBI mailing list