<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]
