I've made some changes here locally which attempt to group fixes to a
bunch of these seemingly related issues. So for PersistentSet.add()
(for example), I have:
public boolean add(Object value) {
Boolean exists = isOperationQueueEnabled() ?
readElementExistence(value) : null;
if ( exists == null ) {
boolean initiallyDirty = isDirty();
write();
boolean actuallyAdded = set.add( value );
if ( !actuallyAdded ) {
if ( ! initiallyDirty && isDirty() ) {
clearDirty();
}
}
return actuallyAdded;
}
else if ( exists.booleanValue() ) {
return false;
}
else {
queueOperation( new SimpleAdd(value) );
return true;
}
}
But I need to get time to properly test these changes before I commit
them.
-----Original Message-----
From: Josh Moore [mailto:josh.moore@gmx.de]
Sent: Thursday, August 31, 2006 7:35 AM
To: Max Andersen
Cc: Steve Ebersole; hibernate-dev(a)lists.jboss.org;
koda2(a)bbs.darktech.org
Subject: Re: [hibernate-dev] Possible to confirm that versioning is
broken forPersistentSets?
Actually had meant doing this in application code. Glad I didn't start.
Thanks to the patch on HHH-1668 from Koda Janh, I could get the HHH-1401
test passing. Had to add a protective if-clause around the write
statement in PeristentSet.clear() similar to Koda's in
PersistentSet.add()/addAll()/remove()/removeAll()/retainAll(). The same
needs to be done for most of the PersistentCollection methods which use
write.
I've got additions to Koda's patch for clear() and PersistentList. I can
take it farther for Map and co., but I saw, Steven, that you changed the
fix version to 3.2.1 for the group of bugs; have you made the changes
already or should I keep extending patch?
A few questions : for all the PersistentCollections which hold a
Collection implementation, these calls could be pushed up into
AbstractPersistentCollection. Is it worth the effort? And finally, what
to do with the Iterators?
~Josh.
Max Rydahl Andersen wrote:
On Tue, 29 Aug 2006 00:45:52 +0200, Josh Moore
<josh.moore(a)gmx.de>
wrote:
> Sorry, myself, if there's nothing more anyone can say to versions
> being broken. Without input, though, I'll assume it's easier to roll
> our own.
If you by "roll our own" means make a fix for it then we would of
course
be interested in it.
As with all existing issues we need to prioritize them and issues with
patches
has a very high tendency to be fixed before issues without patches.
/max
>
> Thanks,
> ~Josh