Most of us relied on this "bug" because it was there. It seemed pretty
cool that the findManyToManyRowset() could return the intersecting
fields without any other form of manual SQL or joins. It really looked
like a feature since it was there prior to 1.8 or even 1.7. And I'm not
sure the documentation said anything about this.
In fact, after you removed it from the codebase, we added it back in our
own because our entire project relies on this kind of functionnality.
Eventually, we'll look into rewriting it someday, but for the moment,
it's bridging the gap.
-- Nicolas
Ralph Schindler wrote:
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
