Just to clarify, what castaway is proposing is to use Ima::DBI methods, in effect skipping Class::DBI. That approach is fine, but it really just sort of skips the power of Class::DBI.

Class::DBI is about getting to your data using methods, not raw hash entries. If you do need to populate a hash (say to pass off to a templating system), then I'd explicitly show the mapping in the code:

# untested code
my %hash = (name    => lc $user->name,
            address => $user->address,
            groupname => $user->group->name);
[download]

In this snippet, you can see I changed the case of the name, and grabbed additional data for the template from another table with an implicit (hidden) join via Class::DBI. (I'm assuming the User class and the Group class were defined with a Class::DBI "has-a" relationship.)

Chaining method calls like this can be very powerful and time-saving.

On the other hand, if you really have 100s of fields in a table, and just want to punt them all over to a hash to go raw into a template system, then I'd suggest subclassing Class::DBI to add the "hashy" function (or an equivalent) offered below.

You'd add the code in one place, and have it in all your Class::DBI::WithHashy classes:

# untested code
my %hash = $user->hashy; # pump all the fields into a hash
[download]

I'm a fan of Class::DBI, I guess.

Best of luck

rkg