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 <st...@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? > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
