Hibernate supports byte[] versions. You can see that org.hibernate.type.BinaryType implements VersionType<byte[]>. [1]
The comment in BinaryType#seed says: // Note : simply returns null for seed() and next() as the only known // application of binary types for versioning is for use with the // TIMESTAMP datatype supported by Sybase and SQL Server, which // are completely db-generated values... There is also a unit test, org.hibernate.test.version.sybase.SybaseTimestampVersioningTest that maps: <version name="timestamp" type="binary" generated="always"> <column name="ts" sql-type="timestamp"/> </version> [1] https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/type/BinaryType.java On Fri, Mar 11, 2016 at 7:36 AM, Emmanuel Bernard <emman...@hibernate.org> wrote: > 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 type byte[]. We definitely do not want all > > byte[] version values to compare as equal. A Comparator needs to be > > implemented at least for PrimitiveByteArrayTypeDescripter. > > > > I'm OK with changing getComparator() for > PrimitiveCharacterArrayTypeDescriptor, > > ByteArrayTypeDescriptor, and > > CharacterArrayTypeDescriptor to return IncomparableComparator.INSTANCE. I > > think that is a safer option than B) (making > > IncomparableComparator.INSTANCE the default if the type is not assignable > > to Comparable). > > > > I'm also OK with using what I implemented in the pull request. > > > > On Thu, Mar 10, 2016 at 7:27 AM, Steve Ebersole <st...@hibernate.org> > wrote: > > > > > 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 <gbad...@redhat.com> wrote: > > > > > >> 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 look at the pull request [1] and let me know if > this > > >> looks reasonable to you. > > >> > > >> Thanks, > > >> Gail > > >> > > >> [1] https://github.com/hibernate/hibernate-orm/pull/1294 > > >> > > >> On Thu, Mar 3, 2016 at 2:44 AM, Gail Badner <gbad...@redhat.com> > wrote: > > >> > > >> > Missed something. Please see below... > > >> > > > >> > On Wed, Mar 2, 2016 at 11:49 PM, Gail Badner <gbad...@redhat.com> > > >> 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 to determine if adding the > > >> current > > >> >> Executable to the end invalidates the sort: > > >> >> > > >> >> if ( previousLast != null && previousLast.compareTo( executable ) > > 0 > > >> ) { > > >> >> sorted = false; > > >> >> } > > >> >> > > >> >> EntityAction#compareTo compares the IDs for the current and > previous > > >> >> EntityAction if they have different entity names; similarly, > > >> >> CollectionAction compares the collection keys for the current and > > >> previous > > >> >> CollectionAction if they have different entity names. > > >> >> > > >> >> In most cases, the ID class implements Comparable, although I don't > > >> know > > >> >> of any requirement that says this needs to be true. > > >> >> > > >> >> This breaks down when a byte[] ID is used as described by > HHH-8999. The > > >> >> reason is that AbstractTypeDescriptor#comparator is null because > it is > > >> >> assigned like this: > > >> >> > > >> >> this.comparator = Comparable.class.isAssignableFrom( type ) > > >> >> ? (Comparator<T>) ComparableComparator.INSTANCE > > >> >> : null; > > >> >> > > >> >> PrimitiveByteArrayTypeDescriptor does not override > > >> >> AbstractTypeDescriptor#getComparator, so null is returned > ultimately > > >> >> causing a NullPointerException in > AbstractStandardBasicType#compare: > > >> >> > > >> >> public final int compare(Object x, Object y) { > > >> >> return javaTypeDescriptor.getComparator().compare( (T) x, (T) > y ); > > >> >> } > > >> >> > > >> >> The same happens for PrimitiveCharacterArrayTypeDescriptor, > > >> >> ByteArrayTypeDescriptor, and CharacterArrayTypeDescriptor. Are > there > > >> others? > > >> >> > > >> >> According to HHH-10413, this also affects version attributes. > > >> >> > > >> >> Here are a couple of alternatives: > > >> >> > > >> >> A) create comparators for PrimitiveCharacterArrayTypeDescriptor, > > >> >> ByteArrayTypeDescriptor, and CharacterArrayTypeDescriptor. > > >> >> > > >> > > > >> > PrimitiveByteArrayTypeDescript should also be in the list for A). > > >> > > > >> > > > >> >> > > >> >> > > >> >> B) Change AbstractTypeDescriptor#comparator to: > > >> >> > > >> >> this.comparator = Comparable.class.isAssignableFrom( type ) > > >> >> ? (Comparator<T>) ComparableComparator.INSTANCE > > >> >> : IncomparableComparator.INSTANCE; > > >> >> > > >> >> IncomparableComparator#compare always returns 0, so that comparison > > >> would > > >> >> never invalidate the sort. > > >> >> > > >> >> > > >> > B) is not acceptable for PrimitiveByteArrayTypeDescripter 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 for PrimitiveByteArrayTypeDescripter. > > >> > > > >> > The following question only applies to > > >> > PrimitiveCharacterArrayTypeDescriptor, ByteArrayTypeDescriptor, and > > >> > CharacterArrayTypeDescriptor. > > >> > > > >> > > > >> >> Does it make sense to sort Executable objects by an ID or > collection > > >> key > > >> >> that is an array? In other words, would such IDs be generated in a > > >> natural > > >> >> order? If not, I think B) makes more sense. > > >> >> > > >> > > > >> >> Thoughts? > > >> >> > > >> >> Thanks, > > >> >> Gail > > >> >> > > >> >> [1] > > >> >> > > >> > https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/engine/spi/ExecutableList.java#L194 > > >> >> > > >> > > > >> > > > >> _______________________________________________ > > >> hibernate-dev mailing list > > >> hibernate-dev@lists.jboss.org > > >> https://lists.jboss.org/mailman/listinfo/hibernate-dev > > >> > > > > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev