[CDBI] Null Column Causing Repeated DB Calls

eric.berg at barclayscapital.com eric.berg at barclayscapital.com
Fri Feb 26 19:24:14 GMT 2010


Thanks, Ed.  I do get beat up occassionally on the performance issue.  This one is particularly egregious given that most of these queries for this particular app will return several thousand rows.

I'd love to hear an alternative to the option below if you've got one.  These data won't be changing very often, so if I instantiate the object with the field in the Essential columns list, then I'm willing to accept that it is in fact null.  Hope my users feel the same way.

Eric

> -----Original Message-----
> From: Edward J. Sabol [mailto:Edward.J.Sabol at nasa.gov] 
> Sent: Friday, February 26, 2010 2:14 PM
> To: Berg, Eric: IT (NYK)
> Cc: classdbi at svr02.digitalcraftsmen.net
> Subject: Re: Null Column Causing Repeated DB Calls
> 
> Eric wrote:
> > The problem appears to be that calls to the accessors for 
> columns with null
> > values is the cause for the additional request to the 
> database. That means
> > that even an assignment, conditional on a "true" value as in
> >
> > my $x = $obj->offending_attribute if $obj->offending_attribute;
> >
> > Still hits the db to get the value, regardless of whether 
> the column is in
> > the Essential or Others column groups.
> 
> Maybe CDBI does that because it's possible the value in the 
> database has been
> changed since object instantiation, but it could very well be 
> unintentional.
> You could try submitting a bug report to RT, but don't expect a quick
> response from Tony. I doubt he'd consider it important 
> behavior to change
> because it would be hard to develop a failing test case for it.
> 
> Database query efficiency wasn't a major design goal for 
> CDBI. It's not for
> most ORMs actually, but some are more efficient than others. 
> I think CDBI's
> design goals were more about correctness and 
> simplicity/elegance (both from
> an implementation point of view and a API point of view). If 
> you need a very
> efficient (but more complex) ORM, then Rose::DB::Object or 
> maybe DBIx::Class
> might be a better choice for you.
> 
> > I wound up doing this:
> [...]
> > But it seems that I'd have to do that for every column that 
> could ever
> > contain a NULL value.
> 
> That seems like a bad idea to me. I wouldn't recommend it.
> 
> Later,
> Ed
> 
_______________________________________________

This e-mail may contain information that is confidential, privileged or otherwise protected from disclosure. If you are not an intended recipient of this e-mail, do not duplicate or redistribute it by any means. Please delete it and any attachments and notify the sender that you have received it in error. Unless specifically indicated, this e-mail is not an offer to buy or sell or a solicitation to buy or sell any securities, investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Barclays. Any views or opinions presented are solely those of the author and do not necessarily represent those of Barclays. This e-mail is subject to terms available at the following link: www.barcap.com/emaildisclaimer. By messaging with Barclays you consent to the foregoing.  Barclays Capital is the investment banking division of Barclays Bank PLC, a company registered in England (number 1026167) with its registered office at 1 Churchill Place, London, E14 5HP.  This email may relate to or be sent from other members of the Barclays Group.
_______________________________________________



More information about the ClassDBI mailing list