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
