Hi, Tim, Thanks for your response! Thanks for drawing my attention to your email yesterday. Acutally I have only searched the mailing list "[EMAIL PROTECTED]" and therefore missed your mails. I should search the both user list and development list for answer first. But, as you know, the archive list is broken (in the db.apache.org/ojb, not in db.apache.org though). Furthermore there is no filtering by time. So a keyword can lead to a vast amount of posts, even though some of them are as far back as early 2002. Very frustrated to go through them.
Back to the subject, I guess the current handling is not very reasonable because to the user the data just mysteriously disappear. Honestly i do not know how the use of proxy can achieve it and would like to learn more about it. (Do you mean we should use proxy class in the class-ref field? Will it mean more work on the user's burden? I did not use proxy before, so please forgive my ignorance :-) If, assuming the original author of assertFkAssignment() think a missing referenced object means an empty FK fields, then at least the checking must be done more throughly. We should at least cater for the case of auto-retrieval. And if we erased the PK we will lost the possibity of update/delete the object further in the db. Do you think it is a good idea to repost this developer list to raise some discussion? Regards, Anthony -----Original Message----- From: Tim Drury [mailto:[EMAIL PROTECTED] Sent: Thursday, March 06, 2003 12:15 PM To: 'OJB Users List' Subject: RE: assertFkAssignment() setting PK fields to null I encountered this just yesterday and got my answer today. Does anyone know if the email archives are going to be fixed soon? > I guess the assetFkAssignment should not set the fields in > class A to null in this case, because the missing of the > referenced object, C, is purposeful. I wonder if > 1) someone has encountered this before? yes > 2) is it a issue? or it is because i have used the > auto-retrieval improperly? It seems to be the desired behavior > 3) If it is a issue, what should be a solution? I guess the > function should not modify PK fields, and better still detect > if auto-retrieval is in effect or not. I cheated and set auto-retrieve to true, but I think the proper way to solve this is via a proxy. > 4) Is it still the case in 0.9.9 and beyond. AFAIK, in 0.9.9, > the function assertFkAssignment is not changed at all? This behavior happens in 0.9.9 and the latest in CVS also. It appears to be planned although it makes no sense to me. -tim Below is the email I got when I asked the same question yesterday: ------------ Tim, OJB after .9.7 started to set the FK to null if the actual reference object is null at the time of storage. This behavior broke my programs and I had to comment out that line from the assertFK...() function inside PersistaeceBrokerSingleVM. I suggested making this an optional trait, to be set in the repository on the reference object, but haven't heard anything from the developers. Caster --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
