Are you trying to say that b == c, because the y are both A objects with the same primary key? Ignoring the fact that if the repository_user.xml states that they are both in the extent of A they cannot have the same primary key, I would argue that b != c. If they are objects of different concrete classes, how can they possibly be equal.
But even so, this does not address my problem. My problem is that, in addition to implementing A, B also extends D. X references D (which happens to be an instance of B). B references an instance of E, which has a back reference to B (as D). [A] interface || [B] --> [E] --> [D] [D] abstract || [B] [X] --> [A] --> [E] --> [D] (x) (b) (e) (b) I hope that comes through alright, and helps to make my situation more clear. Now when x is loaded, b is loaded as a A object. It is stored in the cache, keyed by an Identity object that has A as the topLevelClass. Loading b, causes e to be loaded, which requires that a D be loaded. Even though that D is the same b object previously loaded, we now construct an Identity object with D as the topLevelClass, and search the cache for this key. It is not found, and b is stored into the cache again! I don't see any reason to compare ALL levels of the hierarchy (or all extents). The Identity's objectRealClass field stores the fully qualified path of the objects class. This, with the primary key values, should be sufficient to uniquely identify the actual object. Under this scheme, only one instance of an object would be stored in the cache regardless of how many extents it could exist in. And regardless of how that object was referenced, it would always be found in the cache (assuming that an instance had been previously loaded). Does this make sense? Dave Derry ----- Original Message ----- From: "Gelhar, Wallace Joseph" <[EMAIL PROTECTED]> To: "OJB Users List" <[EMAIL PROTECTED]> Sent: Friday, August 22, 2003 11:45 AM Subject: RE: Potential Identity bug involving mulitple extents. Consider an object hierarchy such as this with all levels mapped as persistent: [A] interface || [B] concrete || [C] concrete B b = new B(1); C c = new C(1); Based on the Identity using the method you propose, b != c even thought the PK matches and they are both A objects. However, we can't simply look at a single "top-level class" either since the object could implement multiple persistent capable interfaces. IMHO, I think the solution has to compare all levels of the hierarchy and the PK to check for equality. -wally -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Friday, August 22, 2003 9:50 AM To: [EMAIL PROTECTED] Subject: Potential Identity bug involving mulitple extents. Posted on behalf of a co-worker: I have just encountered a situation that I THINK is a bug in the Identity object. The equals method compares the topLevelClass, and I think it should be comparing the realClass. I'll try to explain my situation, and I HOPE that I can do so clearly. I have a class AB, which derives from abstract class A, and implements interface B. AB contains a collection of C objects, and the C objects all have a backreference that should point at the AB object but is declared in the repository_user as a reference to B. When the object tree gets loaded, AB loads and is cached with an Identity based on A . OJB loads it's collection of Cs and attempts to resolve the backreference, but looks for one using and Identity based on B, since that is how the repository_user.xml is written. Unfortunately, the cached AB object is keyed by an Identity based on B. Now, when I talk about Identity objects above "based on x", it's because the identity implements hashCode and equals using the "top-level class" of one of the extents. I wonder why we really care about the top level class when trying to identify an object. Any object could potentially exist in any number of extents. If the objects real class matches, and the pkValues are the same, isn't that sufficient (and more accurate than the current method) to identify the object instance? Or am I missing something here? I plan to make these changes and test the result, but thought that it would be a could idea to sound out the list first since it seems like someone else would have run into this before now. Dave Derry --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
