Hi Wally,
I think you are right. If the developer implements .equals() and .hashCode()
and OJB keys the objects on the hashCode then there should be no reason why
we would need to travel up the hierarchy chain. It adds a bit more
complexity to the inheritance implementation on the user's side, but the
optimization, I think, is worth it.
What do OJB gurus think?
--Bill.
----- Original Message -----
From: "Gelhar, Wallace J." <[EMAIL PROTECTED]>
To: "OJB Users List" <[EMAIL PROTECTED]>
Sent: Monday, March 10, 2003 6:57 AM
Subject: RE: Reference descriptor woes
<snip>
There was a reason for this design.
Say there is an abstract class A and a concrete class B extending A. No
say there is a B instance b with a primary key value '17'.
If we do not use the toplevel extent to define Identies it could happen
that OJB addresses this object as A{17} or as B{17}.
this result would violate base rules like
if x == y then id(x) == id(y)
<snip>
I'm confused...Why do you rely on == instead of .equals? As application
developers, we have to correctly implement .equals and .hashCode() to
guarantee identity when using Java 2 Collections. What is the reason
for using the address identity in OJB?
The reason I ask is I have a similar scenario, a base class of Foo with
two derived classes Foo_current and Foo_history used to store to an
"active" table or a "historical" table. Foo_active is an empty class
and history maintains some additional dates. In some cases, I want to
access all Foo's, regardless of active or history, but need efficient
access to the active Foo's when explicitly referenced. Currently, when
I access the Foo_active, OJB will search all Foo_active and Foo_history
(which is rather large) to find the object resulting in very slow
response times.
Any advise?
Wally
---------------------------------------------------------------------
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]
