Re: Getting HASHES out of Class::DBI

Since the documentation for Class::DBI and Ima::DBI are a little too simple, the information is kinda difficult to piece together, however, having experimented around for a few minutes.. You can define your own arbitrary SQL statements, execute and then call Ima::DBI methods on them.. Something like this:

App::User->set_sql('getusers', 'select * from __TABLE__ where username
+ = ?');
[download]

To set up a method named sql_getusers, which can be passed a username, and later to use it:

my $sth = App::User->sql_getusers();
$sth->execute('fred');
my $hash = $sth->fetchall_hash();
[download]

Or any of the other fetch methods listed in Ima::DBI. This one actually gets you an array of hashrefs, one for each of the answers, containing column names as keys, and values in the values.

Class::DBI seems to be good in simple cases, but complex in complicated ones.. (whereas DBI is complex all over, but once you learn it, you'll be able to do everything..

Comment on Re: Getting HASHES out of Class::DBI Select or Download Code

Replies are listed 'Best First'.
Re: Re: Getting HASHES out of Class::DBI by rkg (Hermit) on Jan 07, 2004 at 04:12 UTC
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	[reply] [d/l] [select]
Re: Re: Getting HASHES out of Class::DBI by jdtoronto (Prior) on Jan 07, 2004 at 02:21 UTC
Class::DBI seems to be good in simple cases, but complex in complicated ones.. (whereas DBI is complex all over, but once you learn it, you'll be able to do everything.. Thanks for the input castaway, I have been working with DBI for five years at least, and using things like SQL::Abstract to make life easier for some time as well. I have a feeling I am going back to the DBI. John jdtoronto	[reply]


"be consistent"
	PerlMonks