in reply to Point of AUTOLOAD in a database environment?

There's a good description of something like this in the_damian's book. The key is that when a method call falls into AUTOLOAD, the $AUTOLOAD variable is set to the name of the method that was called. You then basically do something like: 
sub AUTOLOAD {
  my $self=shift;
  my $attr=$AUTOLOAD;
  unless (exists $allowed_attrs{$attr}) die "Hey, that attribute does 
+not exist!\n";
  # %allowed_attrs lists the attributes you are allowed to access
  unless (exists $self->{$attr}) do_get_the_value_from_db(); # do_... 
+would get the value and store it in $self->{$attr};
  return $self->{$attr};
}

[download]
The above code (which is untested, so be warned) implements read accessor type functions. Possibilities explored in the book mentioned include expanding it to get/set accessors and "caching" the function by playing symbol table games, so you only have to go once through the expensive AUTOLOAD mechanism.

CU
Robartes-

Update: To change this to a set type accessor, just change do_get_... etc. to a call to your function that sets the value in the DB (the value is passed in as an argument). You can also define accessor names like set_value and filter out the set_ with a regexp in the AUTOLOAD method.

Replies are listed 'Best First'.
Re: Re: Point of AUTOLOAD in a database environment?
by hossman (Prior) on Nov 15, 2002 at 01:28 UTC

    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};
}

    [download]
[reply]
[d/l]

In Section Seekers of Perl Wisdom