On Mon, Jul 20, 2009 at 6:45 PM, Thomas D. <[email protected]> wrote: > > Hi, > > Andrew wrote: > > So 1.8.4 should resolve this? > > Yes, it's in the current version.
Thanks. I tried it and it's working OK. It's interesting that the code in version 1.8.4 passed the column list as the second parameter of the from() method of Zend_Db_Select whereas the code in 1.8.0 instead used a separate call to the columns() method. It seems to me like those two methods should be equivalent, but obviously they are not. :-) (I also discovered that even with full permissions, the 1.8.0 version didn't work with the way I had to override the limit() method to get it to work correctly in SQL Server 2000. I can't wait until these projects get upgraded to 2005 or 2008.) > > On a tangential note, this is a common issue I seem to have with ZF > > database handling. There is a lot I like about the framework, but it > > does not seem to lend itself to a design paradigm that uses stored > > procedures for database access. True, you CAN execute procedures via > > the framework, but all of these built-in goodies are dependent on > > Zend_Db_Table and lean heavily toward granting full access to all > > objects in the database. It would be nice to see some of the features > > like Db_RecordExists accept arrays and/or Zend_Config instances where > > you could optionally define a procedure name and some parameters > > rather than just a table and column name. > > The framework should work on most environments. Not every Database-Engine > supports stored procedures. > Currently you can just change the used DBE in your configuration file and > your application is still working. I understand that. I'm not even advocating changin the default behavior, since I know how convenient it can be. I would just like to see a config option on some of the libraries so you can pass a procedure name and parameter definitions similar to the way you pass a table and column names currently. Many of the databases supported by ZF do offer stored procedures, so I don't think it's a stretch to offer the option. Zend_Paginator is another class I wish had this as an option. I like the ease of passing a Zend_Db_Select statement into the paginator factory, and would love to be able to do the same with stored procedures. > If you have specific requirements to meet, you can just easily extend any ZF > class. For example, we overwrote the query method in the validator, because > we don't wanted that every column got fetched. > > It wasn't a problem. Extension is definitely the answer, and often it makes more sense to do the extension outside the core. I extended the Db_Adapter and Db_Statement classes to support the Microsoft SQL Server Driver for PHP because it was more reliable than the PDO and mssql libraries for working with SQL Server upon which the ZF classes are built. I just think in this case the extension would be a good addition to the core. > Now, after that got fixed in the current release, we just needed to change > the class names... That's what I'd like to avoid. I don't want to go back through several projects and change a bunch of class names. In this particular case, it works to just push development out to 1.8.4, so I'm happy. Andrew
