Re: Laziness

[prev] [thread] [next] [Date index for 2004/07/15]

At 03:54 2004-07-14, johanl@xxxxxxxxx.xxx wrote:
> I'm sorry if I was unclear. I was expecting all columns to be fetched
> since I thought they would all be in the "All" group (since I set it
> explicitly). But the DBI profile report displayed selects with individual
> columns, as well as selects with all columns.

This didn't have anything to do with laziness after all. Sorry for the
misdirection.

After reading some more DBI traces, I see that the selects of individual
columns is from the "update" method. Just me not reading the manual enough
times. It's a bit much to digest the first time around while trying to get
everything to simply work :)

<http://search.cpan.org/~tmtm/Class-DBI-0.96/lib/Class/DBI.pm#update>;
"After the database update has been executed, the data for columns that
have been updated are deleted from the object. If those columns are
accessed again they'll simply be fetched as needed. This ensures that the
data in the application is consistent with what the database actually
stored."

While I can see why this is an appropriately defensive move, I'm thinking
it might become an unnecessary performance problem in an intense OLTP
application, at least for particular tables and columns (and I realize
CDBI may not be the right tool for that particular job but it would be
nice if it could be, given it's usefulness in other ways).

Are there any ideas in the general area of making the select-after-update
semantics optional like other features? It's not on my nice-to-have-list
now, but it may end up there in the future.


/J