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

Bug #17537 crossLinks errors when using multiple links in links.ini
Submitted: 2010-06-30 10:42 UTC
From: madsliejensen Assigned:
Status: Feedback Package: DB_DataObject_FormBuilder (version 1.0.0)
PHP Version: Irrelevant OS:
Roadmaps: (Not assigned)    
Subscription  
Comments Add Comment Add patch


Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know! Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem : 39 - 34 = ?

 
 [2010-06-30 10:42 UTC] madsliejensen (Mads Lie Jensen)
Description: ------------ DB_DataObject 1.9.4 introduced the ability to specify multiple links for the same field in a table, using array-notation: [table] field[] = secondTable:field field[] = thirdTable:field This will make FormBuilder throw warnings when building crossLinks, and the crossLinks will not work. The building and processing of crossLinks expects DB_DataObject->links() to return a string, but in case of multiple links, it will return an array.

Comments

 [2010-07-01 09:53 UTC] justinpatrin (Justin Patrin)
-Status: Open +Status: Bogus
It sounds like you're defining your links backwards. You want to put the links the other way around in your files. These are defined in the same was a a foreign key in the database. The dependent table (the one that has a column which points to records in another table) is the one that should have the link defined in links.ini. For example, imagine a Parent table with an id column and a Child table with a parent_id column. The links.ini would be: [Child] parent_id = parent:id
 [2010-07-01 10:14 UTC] madsliejensen (Mads Lie Jensen)
-Status: Bogus +Status: Open
The most recent version of DB_DataObject (1.9.4) will let you have a field that is linked to the primary key of multiple tables, according to this: https://pear.php.net/bugs/bug.php?id=16267 When you have that, FormBuilder will through warnings for crosslinks, and the crosslinks will not work. (The options will be shown, but they will all be empty.) I have a table with pictures, one with categories and a pictures_categories to link pictures to multiple categories. Links.ini: [pictures_categories] picture_id[] = pictures:id picture_id[] = extended_view_pictures:id category_id = categoreis:id When workin with the DataObjects, sometimes I need extra info for the pictures, which is provided by a view (extended_view_pictures). The above links.ini will let me join either the picture-table or the extended_view_pictures view, using joinAdd() in DB_DataObject. But when working with formBuilder, the crossLink will throw warnings now, and the will all be not-selected, all because, with the above links.ini, DB_DataObject::links() will return an array, instead of the string that FormBuilder expects. (And I would say that my links.ini is set up as your explanation says it should be?) It is now possible that DB_DataObject::links() returns an array instead of a string. I really think FormBuilder should handle that.
 [2010-07-02 01:48 UTC] justinpatrin (Justin Patrin)
Hmmmm....That feature still isn't making any sense to me. Links are supposed to like a foreign key constraint. It wouldn't make sense to have a foreign key constraint against two tables. A links.ini entry points back to the table that defines the id. I don't understand what the utility of defining links this way would be. The correct link.ini (to me) would be: [pictures_categories] picture_id = pictures:id category_id = categories:id [extended_view_pictures] id = pictures:id Both of these tables point back to the pictures table as it is the root of the id value that is being linked to.
 [2010-07-02 01:50 UTC] justinpatrin (Justin Patrin)
-Status: Open +Status: Feedback
 [2010-07-02 09:40 UTC] madsliejensen (Mads Lie Jensen)
I might (very possibly) be using it the wrong way... But that aside, when FormBuilder is creating crossLinks, it uses DB_DataObject::links(), and then assumes that this always returns a string. As of DB_DataObject 1.9.4, this is no longer the case. links() can now also return an array. If this happens, I think FormBuilder should handle that a little better. I cannot figure out how it should behave if it is an array, perhaps just give a proper error-message that it does not work with arrays returned from DB_DataObject::links() ?
 [2010-07-05 09:30 UTC] alan_k (Alan Knowles)
While the prefered way is to use [Child] parent_id = parent:id Support for field[] = secondTable:field Works with the modular feature introduced in the new version of DataObjects, that allows you to use multiple ini files on a project. (where you may have a core set of tables, which reference tables that may be part of a module that is not installed.) eg. Core.ini [Company] id = ... int .. billing_address_id = ..int.. Accounting.links.ini (the accouting module) - not always used ... [BillingAddresses] id[] = Company:billing_address_id
 [2013-01-31 23:44 UTC] madsliejensen (Mads Lie Jensen)
..by 'handling this' I think it would be enought if FormBuilder gives an error if it encounters an array in this context. I cannot see how FormBuilder would now which entry of the links.ini it should use.