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).
9 years
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
>
9 years
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
9 years
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
9 years
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.
9 years
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
9 years
Master
by Steve Ebersole
I wanted to given everyone a heads up that I just pushed the work I have
been doing up to master. It is alot. It covers most of what was planned
as required for 5.0. The only outstanding item from that initial work is
to integrate the changes into Envers, but I was still waiting to hear back
from Adam and Lukasz about some design questions before proceeding with
that[1].
The main work involved:
1) breaking up Configuration into the bootstrap APIs we have been
discussing. Configuration is still around and works as a mechanism to
build SessionFactory as long as that is all you do.
2) split naming strategy into implicit and explicit contracts.
3) switch from using dom4j to process hbm.xml files to JAXB+StAX
This release I started keeping a working list of changes, ideas, todos, and
things-to-discuss in the repo as working-5.0-migration-guide.md[2]. I will
base the Migration Guide for 5.0 on the top list here, so if you run into
anything that is not covered there and you think should be, let me know.
As for the "TODOs" and "Proposals for discussion" lists, take a look and
let me know if you have any thoughts.
[1] At the moment, this means that the top-level build will not run in its
entirety. It will break as soon as it gets to Envers.
[2]
https://github.com/hibernate/hibernate-orm/blob/master/working-5.0-migrat...
9 years