[hibernate-dev] CI Server
steve at hibernate.org
Mon Mar 23 12:14:21 EDT 2015
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.
> 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.
> 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
> Hopefully I explained that well enough. Anyway... thoughts?
More information about the hibernate-dev