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