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:
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.)# untested code my %hash = (name => lc $user->name, address => $user->address, groupname => $user->group->name);
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
I'm a fan of Class::DBI, I guess.
Best of luck
In reply to Re: Re: Getting HASHES out of Class::DBI
by rkg
in thread Getting HASHES out of Class::DBI
by jdtoronto
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |