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 [email protected], "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: [email protected] [mailto:[EMAIL PROTECTED] On
> Behalf Of parkerwhirlow
> Sent: Friday, December 22, 2006 5:06 PM
> To: [email protected]
> 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
>
