Re: DB Data Object Feature Request

>""Justin Patrin"" <papercrane@gmail.com> schrieb im Newsbeitrag >news:432beae0604281319x2015063fo830987a35cb5eb76@mail.gmail.com... >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. >> > >Also, as a quick fix for this problem while multi-column PK support is >added to DB_DO (who knows when it will actually be done) you can just >add a new column to this table, ID, which has its own sequence. That >way you also have a 1 column PK, which makes it work with DB_DO, and >also have your other data. (note: having your PK be ID would not stop >you from still having a UNIQUE constraint or an INDEX on MessageID, >LanguageID as well). Justin, you are absolutely right that incorporating this feature must be properly evaluated and a patched joinAdd() method is surely not enough. I will put my patched joinAdd() version online next week - maybe someone with more knowledge of the DB_DO internals may decide to try to make the desired changes in other parts of DB_DO. The package could then be released as beta with a big warning so that people can try it out and file their bugs/requests. I understand you reservations and comments. Some of them might be solved by an extended links syntax, e.g. [table1] column1 = table2.column1:a column2 = table2.column2:a column3 = table2:column3:b Where the character at the end indicates which joins belong together. Just a thought ... But I totally agree with Matt that building joins on multiple columns/PKs is an absolutely important requirement for applications being developed for the so-called "enterprise". DB_DO has proven to be a really good basis for this - supporting this would kick ass ;) Regards, Torsten