POST QUESTIONS ON THE FORUM! COMMENTS HERE SHOULD ADD VALUE TO THE
PAGE!On 15 Mar 2004 15:06, hengels wrote:

>On 26 Feb 2004 19:13, RobJellinghaus wrote:
>
>>On 16 Feb 2004 16:02, hengels wrote:
>
>>>what about using the primary key and fall back to object identity if
>a
>>>pk is not assigned?
>
>>This breaks collections because it changes the object's hashcode once
>>you save it.  So you would get:
>
>>UserManager u = session.load(UserManager.class, id);
>
>>User newUser = new User("newUsername1");
>>u.getUserSet().add(newUser); // adds a new Entity with id = null or
>id = 0
>>session.save(newUser);
>>session.flush();             // The id is now assigned to the newUser
>object
>>if (!u.getUserSet().contains(newUser)) System.err.print("OOPS!");
>
>>This *will* print "OOPS!" because newUser's hashcode changed when you
>>saved it, so the userSet can no longer find it.
>
>Huh! Then we need a rehash method on Set and Map ;-) ... or at least
>we could simulate a rehashing by removing and readding all entries.

actually the way I read
http://java.sun.com/j2se/1.4.2/docs/api/java/lang/Object.html#hashCode() 

"the hashCode method must consistently return the same integer, provided
no information used in equals comparisons on the object is modified." 
so provided it isn't the same the integer returned by hashCode() is
allowed to be differend.

"This *will* print "OOPS!" because newUser's hashcode changed when you 
saved it, so the userSet can no longer find it." I expect nothing less tbh.

Because: aren't we going about it the wrong way? Should one alter the
set directly? Yes, no? Ok, let's go with maybe. Now, lets go one step
down, what is a Set(or other Collection)? it's just an collection(you
might be thinking I'm waisting your time but bare with me here). what
has this got to with the entity from which we obtained it? (Other then
that we obtained it from that entity?) nothing! why do we expect magic
to happen? and why would the computer know all this crap and why should
it? If we want to make the set behave differendly from a normal set we
should change how it reacts.

how do we normaly change how an object(better: class?) reacts in the OO
world of today? we either extend the class, wrap/encapsulate it in an
other class etc.

Well extending a Set for every entity is not the way to go(for reasons
obvious I hope) so what about wrapping? yes? no? Lets see don't we
already have it wrapped in that Entity? and what was the other thing we
need? oh yes that relation to the entity, man it all comes togetter. 

instead of calling add() methodes on the list directly create an
addFoo() in which you check for recordUniqueness etc. (in other words
checks if your objects are uqiue on a database record level, and that it
doesn't conflict with constrains) sure you still want to retrive Set's
List's and all that in your code no problem just don't manipulate them,
for savety wrap them in a list that throws
UnsupportedOperationException's if you want to constrain yourself(I would)

in short:
your best stratigy is to make equals and hashcode behave as discribed in
the documentation of Object. and use a differend methode(other then
equal()) altogetter to determent Database record uniqueness. and build
your rules upon that not abuse the equals/hashcode and break it. And a
set should behave as a set.

I hope someone can follow me.