Description: ------------ If you have a table that has a field that is linked to primary ids on multiple tables, db_dataobject fails to find a link to any of them except for the last one. Test script: --------------- ---------- | TABLE1 ---------- | type_id ---------- | obj_id ---------- // table 2 is of type_id=1 ---------- | TABLE2 ---------- | t2_id ---------- // table 3 is of type_id=2 ---------- | TABLE3 ---------- | t3_id ---------- so in the DB.links.ini i would like to have something like [TABLE1] obj_id = TABLE2:t2_id obj_id = TABLE3:t3_id I use userWhereAsOn to provide type_id for the joinAdd Expected result: ---------------- table1->joinAdd(table2) and table1->joinAdd(table3) should work Actual result: -------------- table1->joinAdd(table3) works, but table1->joinAdd(table2) complains: ERROR: joinAdd: table2 has no link with table1 Is there a feature/setting i missed or a workaround until this is fixed/implemented? Please let me know ASAP.

No plans at present to add this, however if you can come up with a patch that does not impact existing usage, feel free to add it to the bug report and I'll add it in.

Thank you for getting back to me Alan. Unfortunately I don't have the time at the moment to learn your implementation and augment it. I was just wondering if there was a quick workaround... Looks like i will have to revert to pure SQL, which extremely unfortunate as there are multiple joins. As a side note, I don't seem to be getting notification emails about comments added to the bug or status changes. I filed the bug and subscribed to it on top of that. That's why i didn't get back to you until now.

I've added a patch - I can't guarantee this won't break anything although it seems OK here. In the links ini file its expecting the keys to be specified as id[] = table1:col1 id[] = table2:col2

Can you try adding a diff patch - it explains what you have changed. http://en.wikipedia.org/wiki/Diff

Added patch Difference.

Hi, hope the patch format is what you meant

Normally it's diff -u (unified) and it would show your new lines as '+' and deleted ones as '-' I've modified it a bit to make it a bit more efficient - could you test it and make sure it works ok for you. http://svn.php.net/repository/pear/packages/DB_DataObject/trunk/DataObject.php Thanks Alan

This bug has been fixed in SVN. If this was a documentation problem, the fix will appear on pear.php.net by the end of next Sunday (CET). If this was a problem with the pear.php.net website, the change should be live shortly. Otherwise, the fix will appear in the package's next release. Thank you for the report and for helping us make PEAR better.

Alan, Many thanks for your patience and speedy help. I just wanted to confirm that the patch is working fine here. Thanks again, Ian PS I don't want to add "me too" but the feature request from my colleague (https://pear.php.net/bugs/bug.php?id=13798) would also be very appreciated

Added patch differencefromsvn.

Sorry Alan. I still had my patch in the subclassed file. I've added a new patch against the SVN file. I've just added the same kind of construct in one other place. Ian

can you check svn again - should be pretty much the same. Regards Alan

Looks good. Many thanks again. Ian

Wow, I've been out of the loop. I just noticed this one. What exactly is the utility of this feature? It was my understanding that links.ini was supposed to define primary keys, not allow linking from one linking table to another (i.e. it defines child record -> parent record relationships, not sibling (cousin?) record relationships). Please see discussion in bug # 17537 for more. http://pear.php.net/bugs/bug.php?id=17537

I'm not sure whether the links is supposed to be strictly primary keys - the user help says "The goal of getlinks and joinAdd is to make connecting two tables as simple and fast as possible, ...". Sometimes when we're using DB_DataObject we're wanting to provide consistent and reliable joining between arbritary tables and not necessarily just primary key relationships. Just my $0.02. Ian