> From: A mailing list for Enterprise JavaBeans development
> [mailto:[EMAIL PROTECTED]]On Behalf Of Dave Wolf
> > For example, Hashtable doesn't specify that equals()/hashCode() need to
> > return the same value after the object has been stored in the table, but
> the
> > behavior is unpredictable if they don't.
>
> But unpredictable to whom? It may very well be someones intention to make
> such a change.
So you are saying that someone might want something along the lines of:
MyObject o1 = ...;
MyKey mk = new MyKey("Cedric");
hashTable.put(mk, o1);
MyObject o2 = (MyObject) hashTable.get(mk);
and have o1 and o2 being different objects?
Because that's what would happen if the semantics of equals() on MyKey was
altered between the put() and the get(). The same goes with primary keys.
Can you provide an example where you would want such a behavior? I'm sure I
can show you a workaround :-)
> Were assuming in a relational model that the primary keys
> are not natural keys. For instance imagine we create a table
> where the name of the company is the natural key. We can therefore create
a
> unique primary key on the companies name. Now, Weblogic Inc, is acquired
and becomes BEA
> Inc. Although we "shouldnt" change the primary key, the key is still the
> natural key and it is still unique.
The natural thing to do in that case is to remove the Weblogic bean and
replace it with BEA. In between, you will have modified its primary key and
probably other attributes as well.
> I believe this points to why the container probobly shouldnt rely on
> equals() and hashCode() of a PK to identify a particular instance of an
> entity bean.
Oh, that's a different matter, then. Sure, we can argue about that. How
would you suggest the container would store and find beans, then?
A stored binary stream is one way of doing it, but it has several
shortcomings: depends on serialization (hence fragile), very low-level (hard
to recover from errors, stream can get corrupted), etc...
Any other thoughts?
At least it's more entertaining than discussing the IT market in India.
Remember the spec says PK classes need equals() and
> hashCode() of the PK class for CLIENTS to keep track of their keys not
> servers. We've already seen this debate with the Fat Key pattern.
True.
I guess this is similar to vtables and C++: nothing in the norm forces any
compiler to implement polymorphism this way, but they all do.
--
Cedric
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
