Subtle behavior change in metamodel with Sort.equals due to the addition of expressions

[njr-11]

The TCK caught a behavior change where it compares a Sort that has a String entity attribute name to a Sort obtained from the metamodel attribute,

        assertEquals(Sort.ascIgnoreCase(_AsciiChar.HEXADECIMAL),
                     _AsciiChar.hexadecimal.ascIgnoreCase());

Previously, both of these were backed by String values and were equal. However, the latter now also has an expression (in this case, _AsciiChar.hexadecimal) causing .equals to report false. Similarly, .hashCode will now compute different values for the two Sort instances as well.

I would argue the new behavior is better because it means _Product.name.asc() will not equal _Employee.name.asc(). However, in Data 1.0, the two were .equals because there was no expression component and the other components (property="name", isAscending=true, ignoreCase=false) all match.

With respect to Sort itself, there is no breaking change. Sort.asc(_Product.NAME) and Sort.asc(_Employee.NAME) are still .equals. The new behavior only applies when an expression is added, which is new in 1.1. The behavior change is really isolated to Sort obtained from TextAttribute. I think we can address this by continuing to obtain Sort without an expression from TextAttribute when the deprecated TextAttributeRecord is used, and defaulting to Sort backed by the TextAttribute as the expression when the TextAttribute.of method that we introduced in Data 1.1 as the recommended approach is used.

[gavinking]

I guess this is OK.