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]
