Bruce,
would you mind sharing your findings/thoughts so far ... ?
Werner
Bruce Snyder wrote:
> This one time, at band camp, Ron Ridenour said:
>
> RR>Thanks for all of your hard work on this project
> RR>and for answering so many emails. It is really
> RR>much appreciated.
> RR>
> RR>My new question is what is the status
> RR>of "Foreign key as part of primary key" bug 925.
> RR>
> RR>Please tell me if I have summarized the bug
> RR>correctly as follows:
> RR>
> RR>I have a table Master with MasterId primary key.
> RR>I have a dependent table Detail with a primary
> RR>key of MasterId.
> RR>Detail.MasterId is a foreign key to Master.MasterId.
> RR>
> RR>Assuming I have diagnosed the bug correctly, I assume
> RR>that the solution is to create a surogate primary
> RR>key on Detail (called DetailId for instance) and then
> RR>Detail.MasterId will no longer be part of the primary
> RR>key.
> RR>
> RR>Assuming that the above surogate key work arround is
> RR>valid, my problem is that I am implementing an application
> RR>against an existing schema that another app is
> RR>already using. I therefore can not change the schema.
> RR>
> RR>I have an additional problem that I wonder if it is also
> RR>a bug. I have a compound primary key in the Detail table.
> RR>Detail.MasterId and Detail.Attribute.
> RR>
> RR>I have declared an array of Detail objects in the Master
> RR>table.
> RR>
> RR>I am getting the following error:
> RR>org.exolab.castor.mapping.MappingException: The number
> RR>of column of foreign keys doesn't not match with what
> RR>specified in manyKey.
> RR>
> RR>Is this the same bug as 925 or is there another bug
> RR>related to compound primary keys.
>
> Ron,
>
> Unfortunately bug #925 is still open. Your assessment of the bug
> is correct but only makes light of one of the two situations. The
> other situation adressess a compound primary key containing one or
> more foreign keys. This problem is also included in the bug report
> for #925.
>
> Your solution is OK for a project where the database schema has not
> yet been implemented. However, on a project that is dealing with a
> database schema that has already been implemented, has been in place
> for a duration of time and contains a large amount of data, this
> will not easily work. Additionally, I don't know of DBA who would
> willingly go through the pains of a data conversion for such a
> solution to be implemented.
>
> I have not yet fully debugged this problem to understand the full
> impact of it. Until I do so, I'm can't say what it might take to
> fix this bug.
>
> Bruce
> --
>
> perl -e 'print unpack("u30","<0G)U8V4\@4VYY9&5R\"F9E<G)E=\$\!F<FEI+F-O;0\`\`");'
>
> -----------------------------------------------------------
> If you wish to unsubscribe from this mailing, send mail to
> [EMAIL PROTECTED] with a subject of:
> unsubscribe castor-dev
-----------------------------------------------------------
If you wish to unsubscribe from this mailing, send mail to
[EMAIL PROTECTED] with a subject of:
unsubscribe castor-dev
