Hey all,
From a code maintenance standpoint, the patch for this issue was
categorized as a "bug". This means the expected behavior was broken,
and is subject to being fixed in any release- Major, Minor, and even
Mini. Issue tracker improvements and feature requests can be included
in Minor releases, and Major proposal style features at Minor and Major
releases as well (Major including any BC breaks).
I'd argue that your use case was outside of any of the intended use
cases for the class, strictly speaking: you were actually RELYING on
buggy behavior.
Row objects should only contain information that the row is actually
modeling. That means that each row object should have the exact number
and type of fields that the database tables has that it originated from.
The safest way of getting any intersection row objects (and data) would
be to use getDependentRowset() on that intersection table. This will
produce a working Row object that you can get the information from, and
update the data (if needed).
I will discuss this with the team.
-ralph
Jurian Sluiman wrote:
On Tuesday 02 Mar 2010 15:46:40 Michael "Ray" Rehbein wrote:
Looks like we have two sides on this. Here are a couple of issues related.
Short version: findManyToManyRowset should not contain extra columns.
http://framework.zend.com/issues/browse/ZF-6232
findManyToManyRowset() returns columns from the intersection table
http://framework.zend.com/issues/browse/ZF-3709
Inconsistent behaviour in Zend_Db_Table and supporting classes
Unit tests were added to match the documented behavior. The extra
columns, as per documentation, were a quirk. There are also a few
cases that the unexpected columns break things. Specifically
triggering the throw:
Row/Abstract.php:
throw new Zend_Db_Table_Row_Exception('The specified Table does not
have the same columns as the Row');
As for getting the profile columns back, this should be helpful:
$select = $db->select()
->from($profileFieldsTableName, array('name'))
->joinInner($profileValuesTableName, 'id=field_id', array('field_id',
'value')) ->where('user_id=?', $user->id);
$profileValues = $db->fetchAll($select);
Thanks for your explanation. My biggest concern is this issue is introduced in
a mini release. My 1.10.0 install worked perfectly and now with 1.10.2 not
anymore.
The removal of the column could help to increase safety and integrity of the
data, but you can't just skip the columns when you have a new mini release. A
chance for a BC problem is large and these changes should only occur in major
or minor releases.
And the last thing, I really liked I could query my data with data mappers.
Now I still need to write the sql myself and that's a pity. I really need to
move all my models into Doctrine soon :)
Regards, Jurian
