Re: Laziness

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

On Thu, Jul 15, 2004 at 01:36:55PM +0200, johanl@xxxxxxxxx.xxx wrote:
> 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.

From the docs:

    If any columns have been updated then the C<after_update> trigger
    is invoked after the database update has executed and is passed:

        ($self, discard_columns => \@discard_columns, rows => $rows)

    (where rows is the return value from the DBI execute() method).

    The trigger code can modify the discard_columns array to affect
    which columns are discarded.

    For example:

        Class->add_trigger(after_update => sub {
                my ($self, %args) = @_;
                my $discard_columns = $args{discard_columns};
                # discard the md5_hash column if any field starting with 'foo'
                # has been updated - because the md5_hash will have been changed
                # by a trigger.
                push @$discard_columns, 'md5_hash' if grep { /^foo/ } @$discard_columns;
        });

Tim.