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

Thanks to the patch on HHH-1668 from Koda Janh, I could get the

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

needs to be done for most of the PersistentCollection methods which

write. I've got additions to Koda's patch for clear() and PersistentList. I

take it farther for Map and co., but I saw, Steven, that you changed

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,

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&gt; 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

> patches > has a very high tendency to be fixed before issues without patches. > > /max > >> Thanks, >> ~Josh