> 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
Anthony - I didn't mean to imply that you should have searched the list first. The list archives are broken and have been since mid-February. The most thorough search possible would not have found the emails exchanged the other day that discussed this issue. > 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 In my object model, all persistent objects inherit a base persistent object which defines the PK, who created the object and when, and who last modified the object and when. This data is also defined in a base interface which defines setters and getters for the PK, who/when created, who/when updated. Because of this, it would be trivial to use this interface as a proxy for any or all of my persistent objects. Instead of turning auto-retrieve off, I would turn it on and OJB would creating instances of this interface to stuff into the object references instead of the actual objects themselves. This would get around the assertFkAssignment() issue because the references would be non-null and updates to the database would also be non- null. > 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. Personally, I don't like the current behavior of assertFKAssignment() putting nulls into the database when the references is null but the FK field is not-null. But, if this were not the case, how would you delete a child object? Doing invoice.setBillToAddress(null); would not work since the FK field would still hold the old FK. Perhaps, a database field would be nulled if both the reference and FK fields are null, but that would require users to intercept calls to set references to null and set the FK field to null also. -tim --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
