[hibernate-dev] CI Server

[Steve Ebersole]

https://hibernate.atlassian.net/browse/HHH-9678

For the time being I will go with the "simpler route".

On Sat, Mar 21, 2015 at 7:15 PM, Steve Ebersole <steve at hibernate.org> wrote:

> 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?
>