Package home | Report new bug | New search | Development Roadmap Status: Open | Feedback | All | Closed Since Version 1.11.5

Request #16267 Linking Multiple Foreign Keys
Submitted: 2009-05-28 00:57 UTC
From: alexchumak Assigned: alan_k
Status: Closed Package: DB_DataObject (version 1.8.10)
PHP Version: 5.1.6 OS: Linux
Roadmaps: (Not assigned)    
Subscription  


 [2009-05-28 00:57 UTC] alexchumak (Alex Chumak)
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.

Comments

 [2009-05-29 09:25 UTC] alan_k (Alan Knowles)
-Status: Open +Status: Feedback
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.
 [2009-06-01 21:11 UTC] alexchumak (Alex Chumak)
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.
 [2010-02-22 15:52 UTC] iancarmichael (Ian Carmichael)
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
 [2010-02-23 10:49 UTC] alan_k (Alan Knowles)
Can you try adding a diff patch - it explains what you have changed. http://en.wikipedia.org/wiki/Diff
 [2010-02-25 21:11 UTC] iancarmichael (Ian Carmichael)
 [2010-02-25 21:12 UTC] iancarmichael (Ian Carmichael)
Hi, hope the patch format is what you meant
 [2010-03-02 08:59 UTC] alan_k (Alan Knowles)
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
 [2010-03-02 08:59 UTC] alan_k (Alan Knowles)
-Status: Feedback +Status: Closed -Assigned To: +Assigned To: alan_k
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.
 [2010-03-04 17:30 UTC] iancarmichael (Ian Carmichael)
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
 [2010-03-04 18:34 UTC] iancarmichael (Ian Carmichael)
 [2010-03-04 18:37 UTC] iancarmichael (Ian Carmichael)
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
 [2010-03-06 05:43 UTC] alan_k (Alan Knowles)
can you check svn again - should be pretty much the same. Regards Alan
 [2010-03-08 20:41 UTC] iancarmichael (Ian Carmichael)
Looks good. Many thanks again. Ian
 [2010-07-02 01:51 UTC] justinpatrin (Justin Patrin)
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
 [2010-07-02 18:04 UTC] iancarmichael (Ian Carmichael)
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