Gelhar, Wallace J. wrote:
<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?
I was unprecise I meant if (x.equals(y) then id(x).equals(y) Of course OJB checks equality and not address identity!
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?
I always thought that this was possible! Maybe we have a code regression here. We'll have to check this issue.
For the time being you could manipulate the extent descriptor at runtime to achieve different query behaviour.
cheers, Thomas
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]
