Re: [hibernate-dev] CI Server

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?