HHH-9322 involves a custom user type for an ID.
On Mon, Mar 14, 2016 at 12:38 AM, Gail Badner wrote:
> In addition to affecting entity IDs [1], this also affects collection keys
> [2].
>
> I've also reproduced a similar problem when an implementation of UserType
> in a composite ID or collection
In addition to affecting entity IDs [1], this also affects collection keys
[2].
I've also reproduced a similar problem when an implementation of UserType
in a composite ID or collection key will fail, unless the implementation
extends Comparator. This is because CustomType#getComparator returns
(C
Hibernate supports byte[] versions. You can see that
org.hibernate.type.BinaryType implements VersionType. [1]
The comment in BinaryType#seed says:
// Note : simply returns null for seed() and next() as the only
known
// application of binary types for
Version can be a byte[] ? I thought JPA was restricting version types
actually.
On Thu 2016-03-10 12:19, Gail Badner wrote:
> As I mentioned before, it is not acceptable for the comparator for
> PrimitiveByteArrayTypeDescripter to be IncomparableComparator because a
> version attribute can be of t
As I mentioned before, it is not acceptable for the comparator for
PrimitiveByteArrayTypeDescripter to be IncomparableComparator because a
version attribute can be of type byte[]. We definitely do not want all
byte[] version values to compare as equal. A Comparator needs to be
implemented at least
Personally I think using IncomparableComparator or null here makes the most
sense. I'm not really sure what the sort ordering of a byte array would
"mean".
On Thu, Mar 10, 2016, 1:41 AM Gail Badner wrote:
> I've created a pull request implements option A) (creates comparators
> for PrimitiveByt
I've created a pull request implements option A) (creates comparators
for PrimitiveByteArrayTypeDescriptor,
PrimitiveCharacterArrayTypeDescriptor, ByteArrayTypeDescriptor, and
CharacterArrayTypeDescriptor.
I'm still not sure if it makes sense to have a comparators for arrays.
Steve, please take a
Missed something. Please see below...
On Wed, Mar 2, 2016 at 11:49 PM, Gail Badner wrote:
> ExecutableList#add attempts to keep track of whether the Executable
> objects are sorted. [1]
>
> Except for entity insert actions (which use InsertActionSorter),
> ExecutableList#add uses the following t
ExecutableList#add attempts to keep track of whether the Executable objects
are sorted. [1]
Except for entity insert actions (which use InsertActionSorter),
ExecutableList#add uses the following to determine if adding the current
Executable to the end invalidates the sort:
if ( previousLast != nu
