CI Server
by 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?
10 years, 9 months
Usage of the Service pattern in Hibernate Search
by Sanne Grinovero
Looks like the ServiceRegistry pattern is getting quite popular in
Hibernate Search.
There are three default implementations (of three services) which are
provided by the hibernate-search-engine itself.
Essentially the hibernate-search-engine code looks it up, and loads
from its very same jar; I'm finding this a bit weird.
Wouldn't it make more sense to actually look up for the service only
for alternative (non-default) implementations?
We don't have a strategy to pick one implementation if there are
multiple implementations around (other than throwing an exception), so
having a service defined in the engine jar, essentially means noone
can plug an alternative, unless he overrides the
SearchConfiguration#getProvidedServices() method.
So if the intention was to allow choice, something is missing. If not,
I'd rather load the default implementations explicitly (via their
traditional constructor).
10 years, 9 months
Re: [hibernate-dev] Sharing an association table between two associations
by Emmanuel Bernard
Oops, Adding the mailing list.
Thanks for the input, we went for two explicit table names in the OGM test. Looks like we are aligned.
Emmanuel
> On 18 mars 2015, at 18:59, Steve Ebersole <steve(a)hibernate.org> wrote:
>
> Well considering I am the only recipient... ;)
>
> I have actually seen this scenario in one of your annotation test cases. Currently, the outcome is actually highly dependent upon the naming strategy used. In my opinion, this should be an invalid mapping. The spec may or may not back me up there, but to me it just "feels" wrong.
>
>
>
>> On Wed, Mar 18, 2015 at 10:27 AM, Emmanuel Bernard <emmanuel(a)hibernate.org> wrote:
>> Hi Steve and all,
>>
>> There is a borderline case that Hibenate OGM trips on. I would like to
>> know whether you consider this case valid enough or if we can safely
>> ignore it.
>>
>> @Entity
>> public class SnowFlake {
>> @Id
>> private String id;
>> private String description;
>> }
>>
>> @Entity
>> public class Cloud {
>> @Id
>> private String id;
>> private String type;
>> private double length;
>> @OneToMany
>> @JoinTable
>> private Set<SnowFlake> producedSnowFlakes = new HashSet<SnowFlake>();
>> @OneToMany
>> @JoinTable
>> private Set<SnowFlake> backupSnowFlakes = new HashSet<SnowFlake>();
>> }
>>
>> Here, producedSnowFlakes and backupSnowFlakes have the set semantic, so a PK is
>> created for the association tables. Except that we use the same association
>> table name Cloud_SnowFlake) for both. The PK offered in Hibernate ORM metadata
>> ends up being wrong.
>> The runtime code works as the target fk columns are named differently.
>>
>> I have always considered it wrong to share the same table for two associations.
>> Are you with me, or should we try to amke the ORM physical model smarter to
>> relax the PK generation when an association table is shared?
>>
>> Emmanuel
>
10 years, 9 months
Hibernate support for JSR-354?
by Elliot Huntington
Hi,
It looks like JSR-354 is progressing nicely and might be included in Java
9. It also looks like the SpringFramework is actively working on including
binding and formatting support for this JSR (
https://jira.spring.io/browse/SPR-12209). Has there been any discussion for
Hibernate to support an out of the box UserType to support persisting a
MonetaryAmount?
I am in the process of writing my own solution but this is the first
UserType I've created and I hope someone here can help me with it. I posted
a question on StackOverflow (
http://stackoverflow.com/questions/29084830/multi-column-usertype-compara...)
about how to customize the sql query that is generated by hibernate for a
custom multi-column UserType. I'm hoping someone reading this mailing list
will be able to provide a helpful answer.
Thank you,
Elliot Huntington
10 years, 9 months
ORM5 : Reusing the Configuration instance
by Sanne Grinovero
Hi all,
I'm trying to get an experimental branch of Hibernate Search to work
with the latest snapshot of Hibernate ORM 5.
After a bit of refactoring of our integration SPIs I thought it was
ready for some testing, but came to some surprising errors from the
ServiceLoader not finding the implementations from Hibernate Search -
although it would find the service definition of it.
After a bit more investigating, it turns out that the Integrator works
fine for each first test of our testsuite; it turns out that the
ClassLoaderService is referenced by the Configuration instance, and
this specific service nulls out all references to classloaders on
shutdown of the SessionFactory (which happens at the end of each of
our tests).
When the second test runs, it's reusing the same instance of ORM's
Configuration and so the ClassLoaderService gets reused and not
properly re-initialized, so it's not able to load any class.
So I'm wondering now if we should stop re-using the Configuration
instance in Search across tests, or if the ClassLoaderService in ORM
should be re-initialized on restart?
(this re-using business is mostly a convenience for how the Search
testsuite works but not strictly necessary)
If we should stop reusing the Configuration instances, then I'd like
to add a validation in ORM as the errormessage thrown from the
java.util.ServiceConfigurationError is confusing.
Thanks,
Sanne
10 years, 9 months
Getting back
by Steve Ebersole
Hey all. Just a heads up that I had been in Big Bend the last few days.
No data service out there; yes, I choose my getaway spots well ;)
Anyway, I will be getting to the emails from the past few days today and
tomorrow.
10 years, 9 months
An update on Jenkins slaves
by Sanne Grinovero
Our ci.hibernate.org now has 3 slaves connected; we can reconfigure
some jobs to use the new slaves already, and gradually move all of them so
that we can re-enable parallel builds, and then scale back on the
compute power of our master node.
The bad news is that I've been waiting 3 hours now for the first build
of Hibernate Search to get at least to run the tests, but it's still
downloading Maven dependencies at the staggering speed of 10Kb/sec.
http://ci.hibernate.org/job/hibernate-search-master/387/console
I'll try to find out if there is something wrong with our
configuration, or maybe Nexus having maintenance, or some maintenance
of the OS1 cloud...
but if not, that's a deal breaker.
Sanne
10 years, 9 months
