Hello,

I have seen the PersistentBag.equalsSnapshot method implementation is quite different from the other collections, and there is neither any comment nor some change in history for explaining that.

The point is, all other collections (including idbag) EqualsSnapshot methods do check each element current value dirtiness against the snapshot element value, while PersistentBag only check they are "same" (which does a reference equality for entity types). Granted, it needs that check for checking their duplication count is same (bag semantics). But shouldn't it check dirtiness too at some point, as all other collections do?

I find such discrepancy suspect, especially since nothing seems to explain it.

In fact, I have seen that first on NHibernate side, and now see it is there in Hibernate too.

Does anyone knows a good reason for this?

Best regards.

I think it's because of the Bag semantics which makes no guarantees about the objects being stored. However, I don't know why this algorithm was chosen. It would be worth to ask the question on the Hibernate mailing list.

Thanks for your insights,

I have posted a message to development mailing list now.

I have also quickly checked current documentation on bags, it does not look like this lack of guarantees is clearly documented.

Anyway, I think this discrepancy may mainly impact the collection holder entity version increment behavior when it has a version, and eventually may impact Envers events logging too. I mean, a change of the state of an entity in a bag would not cause the entity holding the bag to get its version incremented or envers auditing a change, while with a set or idbag it would. So nothing very bad, but may be surprising.

Well, my message was rejected. My mail is not authorized to post to it. If I was supposed to find a user mailing list, not the dev one, then I did not found it.

It works best with GMail. Even with Yahoo there were some issues.