Thanks for the overload suggestion. I can see where I could use it, carefully of course, for autoincrementing or autodecrementing the current row.

I am, though, plowing ahead with a variation of what I suggested above. The My::DB::TIEHASH method tests for the need to load one row or many rows based on a few cases: if there's a "WHERE" clause defined in the parameter -where=>'active = 1' in the tie constructor (any "WHERE" existing assumes multiple rows), or if data passed in through -data has an array of hashes in it instead of a plain hash (many rows).

Right now, my sample code usage goes as follows:

...
tie %th, 'My::DB::User', {-where=>'active=1'};
for (my $i=0; $i < $th{'_ROWCOUNT_'}; $i++)
{   $th{'_CURRENTROW_'} = $i;
    print "$th{'username'} has been an active member since $th{'create
+d'}\n";
}
[download]

I do see a situation where overload could be useful, though. The whole for loop could be avoided by overloading ++ and -- to manipulate $th{'_CURRENTROW_'} like so:

...
while ($th{'_CURRENTROW_'} < $th{'_ROWCOUNT_'})
{   #do something, then:
    $th{'_CURRENTROW_'}++;
}
[download]

I should look into this. I may not need to overload depending on how autoincrement acts on the tied hash already ; I need to test this. As far as my API is concerned, I think it's working out rather well in this case. I can see where it can become a ball of mud, but I'm fighting to keep it simple. Of course, I've not gotten into making the variant subclasses of My::DB for all the remaining tables yet....