Hi Jeff, I tracked it down. The bug is line 662 in this loop (note i vs. k): int k; for (k = i; k < toList.size(); k++) { if (assocType.getIdentityFromItem(toList.get(i)).equals(fromId)) break; }
I'm fixing locally, and also probably going to write a separate routine for non-ordered sets. I realized with your message and looking over it again that it re-orders them even if it's a set. Don't know if this one will make it into 2.0.1, sounds like it may be too late. thanks PW --- In flexcoders@yahoogroups.com, "Jeff Vroom" <[EMAIL PROTECTED]> wrote: > > I don't know of a bug in that code... I can explain what should be > happening. There is probably a more efficient (and simpler) way to do > this when you know you are dealing with an unordered set, but I don't > know why it is breaking right now. > > > > When it hits line 675 for an item which is in both sets, it should have > previously hit the call to remove that very same item a few lines > earlier 671. The code is written so that it is merging two sorted lists > and so it will remove and reinsert an item if it has to shift the > position. Because the position of an item in a Set is can be random, > this may end up doing a lot more work than is necessary. > > > > I think that when it hits the end of the list, it should just be culling > off items that are in the toList which should not be. If the > equals/hashCode methods get messed up, this could easily get messed up > though so that is one thing to check. If the remove call fails to find > the item to remove, things would get out of sync between the set and the > list and I'm not sure what would happen. > > > > For Sets, we probably should just have one loop which iterates over the > "to" list. If the item is not in the from list we remove it from the > toList. Then we loop over the from list and if it is not in the toList > we add it to the toList. If the equals and hashCode methods are not > right for the items in the list and the id properties, this probably > would not fix the problem though. > > > > In terms of recompiling the HibernateAssembler, I think you can just > compile it normally with the WEB-INF/lib classes in your classpath. You > can find HibernateAssembler in one of the flex-messaging jar files and > just replace the old one with the new one. > > > > Jeff > > > > ________________________________ > > From: flexcoders@yahoogroups.com [mailto:[EMAIL PROTECTED] On > Behalf Of parkerwhirlow > Sent: Friday, December 22, 2006 5:06 PM > To: flexcoders@yahoogroups.com > Subject: [flexcoders] Bug using FDS to persist managed association as > Set > > > > This is probably best handled by Jeff Vroom, but I'm open to comments > from anyone.... > > I have dug through the HibernateAssembler source after seeing very > strange behavior, and I think I've uncovered a bug in the > HibernateAssembler. > > When it is persisting a change to a property that is an FDS managed > relationship, and that relationship is a collection mapped as a Set in > Hibernate, it ends up removing a bunch of items from the collection > that should not be removed... > > HibernateAssembler line 591 starts a routine that is supposed to merge > the new collection with the one from the server. > > Because the collection is a PersistentSet, not a List, the variable > isList is false, and it gets an ArrayList from the collection to "have > sequential access". > > while looping through each item in the fromList, even though the item > is in both collections, at line 675 it calls add on toList and toColl. > > toColl is a set, so the add function replaces the existing object > (which it should in case the new one has changed). And the item is > added to the end of the toList. > > After looping through each item in fromList, line 686 removes items > from toColl and toList until they are the same length. I'm not sure > why it is doing this, but it is removing the items from the toColl, > and when done, toColl has much less items in it than it should. > > Is this a known/fixed defect? > > I'm going to start trying to compile this class so that I can > implement a fix for it, but I'm not positive what is needed to do so. > If there is a fix for it already, I'd love to get it. > > thanks, > PW >