Application code should (never?) touch the fooOid, only the referred Foo objects should be manipulated. Likewise for the collections and their parent object id. OJB does the underlying synchronization for you.
But maybe you have some special conditions that sometime require you to bypass this behaviour?
Phil
[EMAIL PROTECTED] wrote:
There are some aspects of OJB that require/encourage having two pieces of data to represent single relationship.
1) When I have an referenceDescriptor, I have to have a fooOid, and a Foo, both of which are two ways of referring to the same thing. 2) When I have a collectionDescriptor, I have a collection on one side, and a fooOid on the other, and sometimes I also have the Foo.
We have repeatedly run into problems where the developer will correctly set one of the many pieces of data, but not all of them. This usually manifests itself as an intermittent bug because the cached objects don't match the objects that are loaded from the database if they're not in the cache.
It would be really cool (IMO) if OJB had a mode that would validate this stuff when it goes to write to the database.
What do the rest of you think?
David
This message contains information from Equifax Inc. which may be confidential and privileged. If you are not an intended recipient, please refrain from any disclosure, copying, distribution or use of this information and note that such actions are prohibited. If you have received this transmission in error, please notify by e-mail [EMAIL PROTECTED]
--------------------------------------------------------------------- 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]
