HHH-16125 POC

[gavinking]

[Failed] proof of concept implementation of PostgreSQL enum support for HHH-16125.

The current implementation of enum support in Hibernate is known to be garbage, involving a UserType and a BasicValueConverter, and this makes it close to impossible to implement this functionality.

[sebersole]

Hmm, you didn't even mention DynamicParameterizedType and friends! ;)

I really did try to move away from all of this for enum mapping in 6.0. There were a few hold ups. One was write-path handling, which is migrated to SQL AST now in 6.2. Another was envers. But maybe with the write-path changes this is possible now. I'll play around with it a bit and see if I can make any quick headway

[sebersole]

For what it is worth, a quick prototype using a ConvertedBasicTypeImpl (rather than the UserType/CustomType combo) for the "non-legacy" aspect of the BasicValue.Resolution works just fine - all hibernate-core and hibernate-envers tests pass.

Unfortunately though, quite a bit of code has been added in the interim that assumes enums are mapped the way they are so there would be work to full clean that up

[sebersole]

I pushed a PR with the simple work - #6246

The crux is EnumeratedValueResolution. It would need additional context, but the building of that Resolution object would be a good place to do all the extra stuff (register aux db objects, prep for query literals, etc)

[gavinking]

oh, awesome, lemme take a look....

[sebersole]

One thing we should nail down is when enums are eligible for handling as native database enum types. E.g. I don't think it makes any sense for converted enums to be map-able using native database enum types. So probably just:

Gender gender;

And perhaps, once we move from HCANN to Jandex -

@Enumerated
Gender gender;

[gavinking]

One thing we should nail down is when enums are eligible for handling as native database enum types. E.g. I don't think it makes any sense for converted enums to be map-able using native database enum types.

Rrrrmmmmm I'm not sure I agree, but to be honest I had not really thought it through.

I kind-of just assumed that @Enumerated(STRING) maps naturally to a MySQL or Postgres enum. This is clearest in the case of MySQL, where enum types are really not much different to a varchar with a check constraint. I see how it's less clear with Postgres, but even so it still seemed natural...

[sebersole]

I guess it depends how you view EnumType#STRING and EnumType#ORDINAL. Is that indicating the storage/type? The JDBC calls we can expect to use to read/write? Both?

We can discuss EnumType#STRING and EnumType#ORDINAL. But more I was delineating that this would not make sense to map using native types:

@Convert(...)
Gender gender;

[gavinking]

Ah, right, yeah,sure, I agree/

[gavinking]

Out of date.