Re: Re: DB_Table: Summary and Pre-Call

Hi, Hans,

Forcing the use of stored procedures also acts as a measure to prevent SQL injection -- since no values are inserted raw (setInt() will cast as integer, setString() will be escaped, etc.). Not perfect, but feels ok :)

Right on. DB_Table actually has a method called recast() that takes an associative array, where the key is the column name and the value is the value to placed in that column; it re-casts the value to the proper type for its column. One would, for example, call $dbtable->recast($data) and then call $dbtable->insert($data). DB_Table can do this because the columns are defined within the class, so it knows what the type should be. I also encourage the use of DB::smartQuote() (DB_Table interfaces to it with the DB_Table::quote() method) to quote-and-escape terms to be used in queries. The automated select() and selectResult() methods help to make this easier.

I'd think it would be fairly simple to have a save() method rather than an update() and insert() method.

At that point it starts looking like a data object class rather than a table interface; DB_Table is the latter, not the former. It may be a subtle difference, but it is an important one. The DB_Table properties are properties of the table, not of the row, which means that save() and those kinds of functions are not the proper metaphor to use. Does that make sense?

Yes, ok -- perhaps that's a misconception on my part. I indeed to do think of DB_Table as a DAO class, but I guess you've been pretty clear about that point. Especially as PEAR already has DB_DataObject, etc. Given that reminder, I'd say that your insert() and update() methods make more sense than a save() method. Seems to me that DB_DataObject could benefit from using DB_Table -- and not the other way around. Is that right?

Oh how I wish it were so. ;-) But the truth is that DB_DataObject serves a different purpose under a different philosophy. As such, DB_Table and DB_DataObject are two different species foraging in the same environment but eating different plants. (Huh? ;-)

Not at all, I enjoy talking about it, and you have made well-reasoned arguments. Certainly there are tradeoffs in DB_Table that are not for everyone, but for me they have worked well, and I like to share when I can.

Yes, it's great work. I think your point that it's not a DAO is a good one. Seems this would be a good addition to PEAR since it provides a solid & re-usable low-level tool. Cool work & good luck :)

Thanks again for your comments, hope all stays well with you. :-) -- Paul M. Jones Savant: the simple alternative to Smarty. http://phpsavant.com/