Re: DB Data Object Feature Request

We have a situation where we have modelled Messages. In our system a Message can be sent out in one or more Languages. The intrinsic meaning of the Message is the same regardless of the Language. Therefore, each Message has a dual part PK (MessageID, LanguageID). Thus, Messages with the same meaning have the same integer PK field and the second part of the PK differentiates each message based on Language. This is the correct modelling of the PK for this subject matter. I was surprised to find out that DB_DataObject didn't support this modelling scenario. I don't think it is a "hack" to support practical, real world scenarios such as this one. Just because DB_DataObject doesn't currently support this scenario doesn't mean it is a hack to support it in the future based on real user needs. Something isn't a hack just because you don't like the idea. For backwards compatibility you could certainly turn this feature off by default and have users turn it on only if they need it. In any case, Torsten should publish his patch to the list so that it can be evaluated. On 4/27/06, Justin Patrin <papercrane@gmail.com> wrote:

On 4/27/06, Torsten Roehr <roehr@zilleon.com> wrote:

""Justin Patrin"" <papercrane@gmail.com> schrieb im Newsbeitrag news:432beae0604271034na1c7199ja0b2ea5fbe6ce60d@mail.gmail.com... On 4/27/06, Matt Friedman <matt.friedman@gmail.com> wrote:

Hi, We've been using a workaround (hack) to deal with an issue that is detailed here: http://pear.php.net/bugs/bug.php?id=4266 Request #4266 Allow joins with multiple keys It looks as though stefan dot doeppert at synapsy dot com has a solution but I'm not sure if anything has been happening on this. Just wondering if anyone has cycles to spend some time on this.

FYI, Adding official support for joins with multiple-column primary keys would entail adding support for multiple-column primary keys to all of DB_DataObject. DB_DataObject doesn't support multiple column primary keys as it is now and this would be a fairly large change, not only for DB_DataObject but for any packages which use DB_DataObject. -- Justin Patrin

It's pretty easy to enable joins on multiple keys for DB_DataObject. All you have to do is patch the joinAdd() method. Instead of exiting the loop when looking for a link in the join definition ALL links must be collected in an array and then concatened to a string in the respective syntax. If there is interest I can post my patch. As long as the patch doesn't allow the same field to be linked *to* mutliple times it *may* be ok, although I suggest it be an option which is normally turned off as, as I said earlier, DB_DO doesn't support multi-column PKs (joining on multiple fields is one way of using multi-column PKs). Why do I want it to only use one version of a *to* field? If you have multiple links from one table to another table (think mother_id, father_id for a person record) then an unscripulous patch would get both. And again, supporting this in just the joins is just a bad idea as it breaks the idea of PKs and links in DB_DO. It is meant to support PKs of only one column, and this implicitly includes supporting links with only one column. This is, at best, a hack, and hacks really shouldn't be introduced into packages. They tend only to cause problems as they work around a problem instead of fixing it. -- Justin Patrin -- PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php

-- -- Matt Friedman