Issues

ZF-7347: Zend_Validate_Db_Abstract can't be used with postgresql schemas

Description

I'm using PostgreSQL and grouping tables in schemas. Unfortunatelly, Zend_Validate_Db_Abstract in __construct accepts only table a column, not schema. When I try use tablename as schema.table, Zend_Db_Select don't accept it as valid table name and throw Zend_Db_Select_Exception: No table has been specified for the FROM clause.

Example of my using of validator $usernameElement = new Zend_Form_Element_Text('username'); $usernameElement->addValidator(new Zend_Validate_Db_RecordExists('user.account', 'username'));

Fixing should be very easy: 1) add schema parameter into __construct of Zend_Validate_Db_Abstract 2) modify _query() line 114 like this: $select->from($this->_table, $this->_field, $this->_schema) and delete line 115 $select->columns($this->_field)

Comments

Some more consideration will be needed to maintain BC here than the suggested solution. The third param is currently the exclude field to be used, and the fourth is to take an adapter in case no default is set.

I will probably change the table parameter to also accept an array with keys schema and table, which would resolve this, and maintain BC.

The problem allsow exists in using this class in DB2/400

I have fixed it...

Attached a file, it's an extention from the Zend_Validate_Db_RecordExists, but the 2 classes I have changed are from the Zend_Validate_Db_Abstract and should be added there...

I have mantained BC by changing the parameter to accept array allsow (as you stated).

BTW, if I would be able to work on this issue, I can submit a fix to the SVN.

There is a little more work to be considered than just the code attached.

There also needs to be documentation and testing changes.

The current test suite uses the sqlite adapter, and so this fix cannot be tested correctly, so the tests also need to be re-factored to use a mock adapter to allow this to be tested correctly.

I will be submitting a fix for all of these points shortly.

Now you rased a point here....

The test adapter is sqllite? Now I know why most of the code does not consider DB2... :((( well more bug fixes...

I do know that there is more to consider than simply posting a fix, I have created it for my project since I am billing a client for it.

As you can see my fix is an extention to the finale work class, so when you will get a fix up I will gladly test it.

But I dont have the time now to create a fix I can document, change PHPTestUnits and submit it.

I would most probably do it, if you would not post a fix in a couple of day's, becouse I would need it for another client, since the database I am working on is not SQLLite or MySQL.

Fixed on trunk in r17157 Merged to 1.9 release branch in r17160

only 1 comment...

    56  +       /**
    57  +        * @var string

53 58 */
54 59 protected $_table = '';

Table can accept Array ("t"=>"table"), and not only string.

10x!

Actually, there is no purpose in accepting an array for the table name, as the alias would never be used. This would only increase overhead, for a completely pointless reason.

Unfortunately incorrect, (I have wasted about an hour to find THAT out...)

when you are working with DB2/400 (as I am doing...) you will find that you mast have it.

Example: Lets say that I have a Schema, Table, Field that I want to check. Without using alias: SELECT Table.Field from Schema.Table where (Table.Field='...')

This SQL would not work on DB2/400 (I have not checked on another versions) If I am adding aliases:

SELECT a.Field FROM SCHEMA.TABLE as a WHERE...

That SQL will work, so what I am pointing is that there is a case when you do need/mast have aliases...

Thank you for bringing this to my attention,

But I believe that this is an underlying problem with the select object. There still would serve no purpose to the component to specify an alias that will not be used.

This is however related to this issue http://framework.zend.com/issues/browse/ZF-4553. (the select should actually read "SELECT Schema.Table.Field FROM"..."WHERE (Schema.Table.Field = "..")

I will chase this up and find out if this is to be fixed shortly.