Re: Class::DBI not intuitive

my $cd = Music::CD->retrieve(1); Retrieve a row (as an object) from the database. Note that this is called as a class method.

my $year = $cd->year; Get a column (a field) from an object. Note that this is called as an instance method, on the particular object retrieved above.

search and search_like are different in that search_like uses the SQL LIKE operator, which allows wildcards. They differ from retrieve in that retrieve only selects based on the primary key, whereas search can use any column or columns. And I think the difference between retrieve and retrieve_all should be obvious just by looking at the name.

Comment on Re: Class::DBI not intuitive Select or Download Code

Replies are listed 'Best First'.
Re^2: Class::DBI not intuitive by pg (Canon) on Jul 27, 2004 at 05:08 UTC
"And I think the difference between retrieve and retrieve_all should be obvious just by looking at the name." itub's explanation was very lucid, and I just want to elaborate a little bit on the quoted comment of his. Other than the obvious difference implicated by the naming, the real concern is performance. It would be quite unwise to do a retrieve_all, when you only care about couple of rows. Indeed the underlying data system might support batch fetch, for example Oracle, this provides the opportunity to fully utilize this and similar kind of functionalities, in the actual implementation, to gain the best performance.	[reply]
Re^3: Class::DBI not intuitive by ryantate (Friar) on Jul 27, 2004 at 21:18 UTC
"... this provides the opportunity to fully utilize this and similar kind of functionalities, in the actual implementation, to gain the best performance." Does anyone know if Class::DBI actually does this? (Uses optimal implementation-specific functionality, for example in Oracle?) I read perldoc Class::DBI and the explanation for retreive_all doesn't say whether it does so. One of the reasons I have avoided Class::DBI is I worry its SQL must be heavily suboptimal to facilitate operation on everything from SQLite to Oracle. I remember reading a comment on PM from someone who was monitoring Class::DBI SQL queries in real time and reported being mildly horrified (I have never been able to find the post).	[reply]
Re^4: Class::DBI not intuitive by drago99 (Sexton) on Jul 28, 2004 at 04:23 UTC
There is Class::DBI::Oracle which could be used also, in place of Class::DBI (it subclasses Class::DBI). If/where you find sub-optimal SQL in Class::DBI, simply replace it inside Class::DBI::Oracle. When you've made some nice improvements, send in a patch so the rest of us can benefit. Look at Class::DBI as a starting point rather than an ending point.	[reply]