[hibernate-dev] CI Server

[Steve Ebersole]

I just finished work on HHH-8697 and HHH-9320 and pushed that work to
master and 4.3.  After my push, the CI jobs for each started failing in a
way I could not reproduce locally.  But I did eventually divine what was
going on.  The failure is actually indicative of problem elsewhere.  And it
may or may not be a problem outside of our test suite.  The issue is with
fact that we register org.hibernate.type.descriptor.sql.SqlTypeDescriptor
instances with
a org.hibernate.type.descriptor.sql.SqlTypeDescriptorRegistry that is
unfortunately for now defined statically via a static INSTANCE variable.
Our SqlTypeDescriptor implementations register themselves with the registry
on creation.

<backstory>
This is all code I added for implementing AttributeConverter support.  When
we see an AttributeConverter we use the defined "database type" to perform
a resolution from the defined type to the recommended JDBC style code for
that type, and we then ask the SqlTypeDescriptorRegistry for the
SqlTypeDescriptor corresponding to that JDBC type code.
</backstory>

There is a test that subclasses our internal VarcharTypeDescriptor.
VarcharTypeDescriptor, like all the SqlTypeDescriptor impls, registers
itself with the SqlTypeDescriptorRegistry during its instantiation.  The
"issue" here is that this subclass also registers itself into the
SqlTypeDescriptorRegistry during its instantiation via the call to the
super ctor.  And because the SqlTypeDescriptorRegistry is static, this
causes the "bleeding".

How to fix this?  There are a few options.  Ideally
SqlTypeDescriptorRegistry would not be static and we could just move on.
However that is not possible given the current design of Types.  Now this
does feed into some changes I wanted to make as we move forward in the Type
system.  As I was developing our AttributeConverter support I thought it
would be really awesome if a Type (a BasicType anyway) was just a dynamic
combining of a SqlTypeDescriptor and a JavaTypeDescriptor (unless a
specific Type was named).  Take a counter-example.  Today we have multiple
Type impls to deal with storing a UUID (UUIDCharType, UUIDBinaryType,
PostgresUUIDType).  But literally these are all just 3 different combinings
of SqlTypeDescriptor and JavaTypeDescriptor:
* UUIDCharType is a combo of UUIDTypeDescriptor and VarcharTypeDescriptor
* UUIDBinaryType is a combo of UUIDTypeDescriptor and BinaryTypeDescriptor
* PostgresUUIDType is a combo of UUIDTypeDescriptor and a specialed
pgsql-specific SqlTypeDescriptor for its UUID dtype.

The idea is similar to what I stated above in the backstory when
determining an implicit type.  Today we use the java attribute type to do a
look up into the based on registration keys *for the Type*.  Instead in
this future model we would use the java attribute type to determine the
recommended JDBC type code (String->Types.VARCHAR, etc) and then use that
JDBC type code to determine the SqlTypeDescriptor to use.  Then combine
that with the JavaTypeDescriptor for the java attribute type.  This
approach has a lot of potential benefits including the ability to
leverage java.sql.DatabaseMetaData#getTypeInfo.  The benefits aside, this
is a big change, so I am not sure it is best to take that on for 5.0.

The other solution I can think of for now is basically to limit what gets
added to the SqlTypeDescriptorRegistry so that it is just Hibernate defined
SqlTypeDescriptors.

Hopefully I explained that well enough.  Anyway... thoughts?