I don't know if I qualify as OJB guru, but I have some thoughts here. From a "java" point of view it would be easy to identify objects on a .equals() and .hashCode() basis.
But OJB must also maintain object identity accross several JVMs and one or more RDBMS.
IMO there is no other way than the existing Identity concept to deal with it.
(As I mentioned in an other mail already the rule should go if x.equals(y) then id(x).equals(id(y)
and also very important: if (! id(x).equals(id(y))) then (! x.equals(y)) )
But we will have to check if there is a bug in situations where you are performing queries against a concrete class and not the top-level class.
cheers, Thomas
V.B. Skrypnyk wrote:
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]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
