A particularly cool variation on this theme, is when you have different 'levels' of data, with increasing cost of retrieval from your datastore.
For example, assume you have a database of people, with very basic data bout them stored in a "People" table, one row per person, keyed on SSN. Other less frequently data is stored in a variety of other tables (ie: all of their grades from every class they ever took is stored in some table keyed by SSN & year; their current & historic clothing sizes are another table keyed by SSN, year & clothing-type; etc..). And still more data about the person is very aggregate in nature, and requires 'expensive' computation (ie: their grade to waste size ratio for each year)
If you typically only care about the "core" data on a person, and occasionally care about their clothing sizes, and very infrequently care about *ALL* of the data you have on them, then you can divide up the data by how easy/fast it can be retrieved, and change your %allowed_attrs hash into an %attr_populator hash, that stores a method ref you can call to retrive data at that level -- if it hasn't allready been retrived. so in the common case, you are only calling the very fast _get_core_data() method, but when neccessary you call the more obscure _get_clothing_sizes() method.
Something along the lines of...
%attr_populator = { name => \_get_core_data, bday => \_get_core_data, sizes => \_get_clothing_sizes_data, grades => \_get_grade_data, complex => \_get_really_expensive_data, }; sub AUTOLOAD { my $self=shift; my $attr=$AUTOLOAD; unless (exists $attr_populator{$attr}) die "Hey, that attribute does + not exist!\n"; &{$att_populator{$attr}}($self) unless (exists $self->{$attr}) return $self->{$attr}; }
In reply to Re: Re: Point of AUTOLOAD in a database environment?
by hossman
in thread Point of AUTOLOAD in a database environment?
by janjan
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |