[Hibernate] BindHelper.findPropertiesByColumns behaviour is non deterministic due to HashSet being used.

[<Ron...@to...>]

Hi Emmanuel,

I think we might have found a bug in BindHelper.bindPropertiesByColumns, 
want to run by you to see if it's worth while submitting to Jira.

What we are trying to do is to associate two attributes of the same type 
to an object.

i.e.,

class Deal {
  @ManyToOne
  @JoinColumn(name = "a_customer_id", referencedColumnName = 
"customer_id", nullable = true)
  Customer a;
 
 @ManyToOne
 @JoinColumn(name = "b_customer_id", referencedColumnName = "customer_id", 
nullable = true)
 Customer b;
}

// note: customer id is not a pk
class Customer {
  @Column(name = "customer_id")
  String customerId; 
}

When loading deal object, customer a is always populated correctly but 
customer b will only be populated occasionally (depending on your luck!).

After digging through Hibernate annotation source, I think I've found the 
cause of the problem in BindHelper.bindPropertiesByColumns where HashSet 
is being used.

From looking through the source, my understanding is that hibernate will 
create a synthetic property for each of the customer Deal.a and Deal.b and 
add it to a list of properties type mapping within Customer persistent 
class object. This type mapping is then used to hydrate Deal.a and Deal.b 
when Deal object is being resolved.

When synthetic property for Deal.a is being created, the propertymapping 
is straight forward because only customerId property is available in the 
Customer persistent class. Deal.a is then mapped simply to a simple type 
of Customer.customerId.

Subsequently, when synthetic property for Deal.b is being created 
(BindHelper:97), the property mapping has two possible values - one is the 
Customer.customerId, the other is the recently created synthetic mapping 
(_Deal_a). These two values are extracted out and put into a HashSet 
(BindHelper.bindPropertiesByColumn:190). The hashset is then the being 
iterated through to return the first value of iterator (which the order is 
not guaranteed). Obviously it would be wrong to create a synthetic 
property for Deal.b with synthetic property _Deal_a type mapping (which is 
what occasionally happens). 

Upon load, hibernate core will then attempt to hydrate Deal.a by 
instantiating Customer (_Deal_a) type object and inject a_customer_id into 
an instance of _Deal_a type. This will result in a correct load. 

When hibernate core attempt to hydrate Deal.b, it will instantiate 
Customer (_Deal_b) type object. However, _Deal_b type object mapps to an 
embedded _Deal_a type. So it will then recurse through the embedded type, 
instantiate Customer (_Deal_a) type object, assign b_customer_id into 
embedded Customer.customerId after which instance of Customer(_Deal_a) 
will be assigned to Customer.customerId (_Deal_b). This assignment is done 
via EmbeddedPropertyAccessor.EmbeddedSetter.set method - which looks like 
a null implementation. The result is that Deal.b won't be set and no 
errors is being reported at all. What worst is that the system can appear 
to have been working most of the time, but if you add additional attribute 
to class Deal to disturb the balance of the hashcode generation, then all 
of the sudden it won't work.

I can think of a couple of fixes in BindHelper.bindPropertiesByColumns:
1. Instead of using HashSet we use an ordered set to guarantee the order, 
this way the native properties will always be returned first.
2. Use List instead of Set to guarantee the order - the values being added 
in to the columnsToProperty map can never be null or repeated anyway.
3. Filter out all of the synthetic properties from columnsToProperty 
mapping (this propbably wouldn't help for muti column mapping?).

BTW: It also perplex me why EmbeddedPropertyAccessor.EmbeddedSetter.set 
method would do nothing and report no error when it can't set the 
property.

Sorry for the lengthy email but it's a fairly subtle bug that can't always 
be replicated so I thought it's worth while explaining in details. Let me 
know if you want me to submit this to Jira. We have opted for option 2 on 
local fix and it appear to be working well.

Regards,
rOnn c.

######################################################################
DISCLAIMER:
This email and any attachment may contain confidential information.
If you are not the intended recipient you are not authorized to copy
or disclose all or any part of it without the prior written consent
of Toyota.

Opinions expressed in this email and any attachments are those of the
sender and not necessarily the opinions of Toyota.
Please scan this email and any attachment(s) for viruses.
Toyota does not accept any responsibility for problems caused by
viruses, whether it is Toyota's fault or not.
######################################################################