Re: DB Data Object Feature Request

On 4/28/06, Matt Friedman <matt.friedman@gmail.com> wrote:

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.

Yes, this does make sense in theory. Unfortunately, as I have stated, DB_DataObject does not support this, as I have stated many times now.

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.

It is not a hack "because I don't like the idea" and it is not a hack "because DB_DataObject doesn't support the scneario". It is a hack because it is a patch to *one* of DB_DataObject's methods to support this kind of thing. It does not take into account, for instance, the get() function, and it doesn't specify how multi-column PKs are to be enumerated in the db.ini file ro how multi-column links are to be enumerated in the db.links.ini file. Please re-read my previous e-mail, I was explaining that what I thought he said his patch did could very likely be broken. Assuming that if table A has 2 fields which link to table B constitutes a multi-column PK is a hack. What if you had *2* total links to that table? How do you differentiate them? What if you simply have a single-column PK but table A has 2 fields which link to table B? Will this code assume that they are a multi-column link? This is what I meant when I said it is a hack. Unless the patch handles PKs in every part of DB_DO and makes it a supported feature then it is either a hack or unfinished. In this case it sounds very much like a hack. I am not against multi-column PK support in DB_DO. I'm just pointing out that it needs to be implemented consistently as a multi-column PK feature, not as a "hack to link on multiple columns".

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.

Puslishing the patch is fine. You can even use it if you like, this is Open Source and you're free to do what you want. I doubt that the patch will get into DB_DO as-is, though, at least not without some work on the rest of the DB_DO code to support this feature fully. (As a side-note, my work on FormBuilder2 already supports multi-column PKs, although it does not yet support DB_DO.)

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 -- PEAR Development Mailing List (http://pear.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php

-- Justin Patrin