Delivery reports about your e-mail
by Post Office
The original message was received at Sun, 28 Feb 2016 13:03:35 +0800
from lists.jboss.org [71.210.55.172]
----- The following addresses had permanent fatal errors -----
<hibernate-dev(a)lists.jboss.org>
7 years, 3 months
Welcome Martin Braun to the Hibernate committers club!
by Sanne Grinovero
Hi all,
Martin has been contributing to Hibernate Search since a year, and
developed some very interesting extensions this summer in the scope of
Google Summer of Code, and is still
evolving those and generally helping and monitoring the project.
He recently volunteered to try helping us with pull request review
duty, and today he
survived my most annoying and pedantic review, forcing him to show off
with pretty
advanced Git-fu and managing a complex rebase :)
So we decided to award him with a set of keys to the reference
repository, and he just pushed his first PR!
Martin: do you want to introduce yourself to the others? I suspect
you're the youngest committer we ever had?
Welcome again!
Sanne
7 years, 3 months
[Search] Elasticsearch - Thoughts about analyzers and fieldbridges
by Guillaume Smet
Hi,
Running the DSLTest is quite interesting as it runs a lot of different
queries with different configurations.
Here are some thoughts while working on it.
1/ Analyzers
=========
Gunnar, I was wondering what you had in mind for analyzers: a) deal with
them in Hibernate Search or b) let Elasticsearch do the analyze thingy.
I'm not sure we can get a/ to work correctly (see below) and for b) we're
going to need a way to disable the analyzers in Search for the entities
managed by Elasticsearch.
Take a phrase query "colder and whitening" extracted from DSLTest. As "and"
is considered a stopword, the resulting PhraseQuery only contains colder &
whitening so it's not possible to rebuild the phrase before sending it to
Elasticsearch. We could try to use span queries but I'm not sure we'll be
able to get it right with synonyms and so on.
2/ FieldBridges
===========
Currently, the conversion from Date to JSON string is managed by a
fieldbridge specific to the Elasticsearch backend (and it's not that easy
to plug it in as we have seen it in a ticket).
I'm wondering if it's a good fit and if we should not invent an entirely
new thing to deal with the transformation between a given Java type and
what a backend is waiting for.
What made me think of it is that a test from DSLTest is using
ignoreFieldBridge() on a date field and it disables the Date -> JSON string
conversion entirely.
Comments, thoughts?
--
Guillaume
7 years, 3 months
Dealing with CI failures due to javadoc warnings during spikes
by Sanne Grinovero
We're doing fast iterations on the experimental Elasticsearch support
for Hibernate Search,
and by doing so there have been introduced temporary changes so we can
make progress while sharing code with each other.
CI is used to highly polished code, so it's failing the builds for
petty warning like an @arg or @return missing on a javadoc documented
method.
I'm proposing to disable this validation and open a JIRA to fix all
javadocs at the end of the iteration, i.e. making it a blocker task
for a candidate release, yet ignore them until we get so far.
Or would you rather try to keep javadoc polished during the process?
Thanks,
Sanne
7 years, 3 months
Hibernate and JSR-107 (was Re: 5.1 tentative release date)
by Steve Ebersole
That's awesome to hear Louis!
As for getting help with the Hibernate side, discussing here is probably
the best option IMO. But really whatever feels most comfortable to you: you
can ask here, ping us on #hibernate-dev IRC or on our HipChat channel[1].
[1] https://hibernate.hipchat.com/chat/room/1238636
On Wed, Feb 24, 2016 at 9:49 AM Louis Jacomet <ljacomet(a)gmail.com> wrote:
> Hi all,
>
> I am interested in helping finalising that JSR-107 H2LC.
>
> I will start looking into the code Alex has on his branch on github and
> take it from there. I may need to ping hibernate devs directly at one point
> since I do not have a very good knowledge of Hibernate currently.
>
> Regards,
> Louis
>
> On Thu, Jan 14, 2016 at 3:45 PM Petar Tahchiev <paranoiabla(a)gmail.com>
> wrote:
>
>> Exactly,
>>
>> I'm struggling to find a JSR-107 second-level cache to plug in my
>> project. EHCache 3.x does not integrate with hibernate yet, neither does
>> hazelcast - they have a PR, but they'll merge it in the next couple of
>> months. Oracle Coherence I think is paid, so is IBM extremescale and
>> Grigain. JCS has a one-year old beta release, which I'm not sure is jcache
>> compliant, and Infinispan, as I understand, works as a separate service,
>> and I want to have it embedded in my spring project. This is really
>> embarrassing - a cache is essential to any application and seems like there
>> is no free, robust, open-source, embeddable, JSR-107-compatible cache
>> implementation.
>>
>> 2016-01-14 16:31 GMT+02:00 Steve Ebersole <steve(a)hibernate.org>:
>>
>>> So then it sounds like "no" to this, which is fine. We already have
>>> updated to a much newer Ehcache and as pointed out earlier the stability in
>>> the Ehcache API actually used in the integration means any 2.x version of
>>> Ehcache should be fine to drop in.
>>>
>>> Ehcache 3.x support will be based on that JSR 107 work...
>>>
>>>
>>> On Mon, Jan 11, 2016 at 10:50 AM Alex Snaps <alex.snaps(a)gmail.com>
>>> wrote:
>>>
>>>> Right, there was no plan to provide something for Ehcache3 quite yet.
>>>> That being said, I wonder whether we ever will. I have a 107 compliant
>>>> H2LC implementation. I also went over it with Sanne during Javaone and we
>>>> think it can be made into something suiting for bunch of providers.
>>>> Now, small caveat, while I still plan to work on this, as of this year
>>>> I'm not working for Terracotta anymore... Basically, that's whenever I'll
>>>> find time to do so.
>>>> cc'ed Louis, in case some he wants to provide some more formal
>>>> stance...
>>>> Alex
>>>>
>>>>
>>>> On Mon, Jan 11, 2016 at 11:00 AM Steve Ebersole <steve(a)hibernate.org>
>>>> wrote:
>>>>
>>>>> Petar, Alex Snaps (in CC) has been doing some work to update the
>>>>> version of Ehcache used in Hibernate ORM. Alex, any updates? As I
>>>>> understood it though Ehcache 3.x was not part of that effort, but Alex can
>>>>> of course say for sure.
>>>>>
>>>>>
>>>>>
>>>>> On Sat, Jan 9, 2016 at 3:25 AM Petar Tahchiev <paranoiabla(a)gmail.com>
>>>>> wrote:
>>>>>
>>>>>> Hello all,
>>>>>>
>>>>>> I just saw ehcache 3.0.Alpha is already out. Any chance to have the
>>>>>> hibernate-ehcache module updated in 5.1?
>>>>>>
>>>>>> 2016-01-09 5:00 GMT+02:00 Scott Marlow <smarlow(a)redhat.com>:
>>>>>>
>>>>>>> I'll create a jira for the Javassist to be part of 5.1.
>>>>>>>
>>>>>>> Should we also look at changing Hibernate to not require Javassist
>>>>>>> classes be on the deployment classpath? This might require cloning
>>>>>>> some
>>>>>>> Javassist runtime classes so that we don't get CNFE on
>>>>>>> javassist.util.proxy.ProxyObject (and whatever else is required by
>>>>>>> enhanced entity classes).
>>>>>>>
>>>>>>> [1] contains one of the CNFE's that I see with WildFly during
>>>>>>> deployment
>>>>>>> time (only if WildFly is hacked to not inject Javassist into the
>>>>>>> application classpath). I am seeing
>>>>>>> org.hibernate.proxy.pojo.javassist.JavassistProxyFactory enhance the
>>>>>>> entity class with references to Javassist classes (see disassembled
>>>>>>> bytecode output [2]). The generated class extends
>>>>>>> javassist.util.proxy.ProxyObject +
>>>>>>> javassist.util.proxy.MethodHandler. +
>>>>>>> javassist.util.proxy.RuntimeSupport +
>>>>>>> javassist.util.proxy.SerializedProxy.
>>>>>>>
>>>>>>> I'm sure that there are other Javassist classes that we probably also
>>>>>>> generate bytecode to depend on, in other places in Hibernate.
>>>>>>>
>>>>>>> I have no idea exactly how to resolve this. I'm not sure if it would
>>>>>>> entail cloning the above javassist runtime classes into javassist.
>>>>>>> Or
>>>>>>> separating them into a different (Javassist) library, so at least the
>>>>>>> application doesn't include the other Javassist classes.
>>>>>>>
>>>>>>> Sanne had some ideas that he mentioned [3]. By only exposing the
>>>>>>> needed
>>>>>>> classloaders to the deployment, I think he meant the above idea of
>>>>>>> separating Javassist into different jars. Or something like that.
>>>>>>>
>>>>>>> Jason Greene also liked Sanne's suggestion of not requiring
>>>>>>> applications
>>>>>>> to have Javassist on their classpath, as applications might also
>>>>>>> include
>>>>>>> their own copy of Javassist because they want to generate some
>>>>>>> bytecode
>>>>>>> also.
>>>>>>>
>>>>>>> What do others think about the idea of not requiring Javassist to be
>>>>>>> on
>>>>>>> the Hibernate application classpath? Again, I'm not sure if this
>>>>>>> only a
>>>>>>> problem on WildFly. If it is, I'm not sure why. :)
>>>>>>>
>>>>>>> Scott
>>>>>>>
>>>>>>> [1]
>>>>>>>
>>>>>>> https://gist.github.com/scottmarlow/4e23e62962101b740a4a#file-gistfile1-t...
>>>>>>>
>>>>>>> [2] https://gist.github.com/scottmarlow/dc7ebfea654984f84e2e
>>>>>>>
>>>>>>> [3]
>>>>>>> https://github.com/wildfly/wildfly/pull/8474#issuecomment-162698801
>>>>>>>
>>>>>>> On 01/08/2016 02:49 PM, Steve Ebersole wrote:
>>>>>>> > I don't see a Jira to upgrade Javassist as part of 5.1...
>>>>>>> >
>>>>>>> >
>>>>>>> > On Fri, Jan 8, 2016 at 1:35 PM Scott Marlow <smarlow(a)redhat.com
>>>>>>> > <mailto:smarlow@redhat.com>> wrote:
>>>>>>> >
>>>>>>> > Should we upgrade to javassist latest in 5.1 still?
>>>>>>> >
>>>>>>> > On 01/08/2016 10:08 AM, Steve Ebersole wrote:
>>>>>>> > > Just a heads up that I tentatively set Jan 27th as the
>>>>>>> release
>>>>>>> > date for
>>>>>>> > > 5.1. Please let me know if that does not work for anyone.
>>>>>>> Also
>>>>>>> > please
>>>>>>> > > keep that date in mind if there is anything you want to get
>>>>>>> into 5.1.
>>>>>>> > > _______________________________________________
>>>>>>> > > hibernate-dev mailing list
>>>>>>> > > hibernate-dev(a)lists.jboss.org <mailto:
>>>>>>> hibernate-dev(a)lists.jboss.org>
>>>>>>>
>>>>>> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>> > >
>>>>>>> >
>>>>>>> _______________________________________________
>>>>>>> hibernate-dev mailing list
>>>>>>> hibernate-dev(a)lists.jboss.org
>>>>>>>
>>>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Regards, Petar!
>>>>>> Karlovo, Bulgaria.
>>>>>> ---
>>>>>> Public PGP Key at:
>>>>>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
>>>>>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611
>>>>>>
>>>>>
>>
>>
>> --
>> Regards, Petar!
>> Karlovo, Bulgaria.
>> ---
>> Public PGP Key at:
>> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x19658550C3110611
>> Key Fingerprint: A369 A7EE 61BC 93A3 CDFF 55A5 1965 8550 C311 0611
>>
>
7 years, 3 months
[HSEARCH] Implementing mass indexer with JSR 352 batch application
by Gunnar Morling
Hi,
I've been contemplating the idea of creating a JSR-352-style batch
application for re-indexing one or more entity types in Hibernate
Search.
Functionally, it'd be the same as the current mass indexer, but using
JSR 352 would provide some nice benefits:
* Operation through standard batch interfaces (e.g. CLI, web console
or whatever servers provide)
* Standardized monitoring and logging
* Standardized error handling, restartability after failures
I thought this might be an interesting GSoC idea.
It's very isolated and also should not be too complex to do. If the
student is quick, one further idea could be to provide some UI
functionality for controlling this (I'm not sure what's already
available in the WF web console).
Any thoughts?
Thanks,
--Gunnar
7 years, 3 months
HSEARCH-1917, faceting, indexNullAs, FieldBridges
by Guillaume Smet
Hi,
While looking at HSEARCH-1917 which is an issue with faceting and null
values, I came up with the following observations:
1/ Faceting doesn't take into account indexNullAs
2/ Faceting doesn't take into account FieldBridges
1/
In HSEARCH-1917, Hardy talked about supporting indexNullAs.
Does it make sense for everyone?
I don't have a strong opinion about it and if we answer no to 2/ for the
time being, maybe it's better to not support it for now (but I would fix
the faceting on null values anyway).
2/
FieldBridges are also not supported by faceting. In the case of a
TwoWayFieldBridge, we could consider applying the FieldBridge to the values
before storing them in the facet field.
One thing that made me think about it is that, currently, with the
Elasticsearch backend, facet values are created from the indexed field so
they take into account the FieldBridge.
Well, apart if it's a facet which has a name different from the field. Then
the facet values are extracted from the facet values created in the Lucene
document. In this case, the behavior is similar to the Lucene backend
behavior.
My current opinion is that we should for now fix HSEARCH-1917 by adding a
if (value == null) return; at the top of addFacetDocValues and revisit the
2 subjects later for 6.
Anyone against me creating an issue to centralize all the things we need to
fix in FieldBridges/Document building for 6? I would rather create a single
issue for now so that we keep an overview of all we need to fix before
defining exactly what we want to do.
--
Guillaume
7 years, 3 months
Naming strategies and join tables
by Guillaume Smet
Hi,
I'm migrating another application to 5.x and have the following issue with
the new naming strategies.
We used EJB3NamingStrategy and are now using
ImplicitNamingStrategy*Legacy*JpaImpl which is advertised as being its
replacement.
The model is the following:
@Entity
AbstractProjet
> @Entity
@DiscriminatorValue(value = "ProjetDiffusion")
public class ProjetDiffusion extends AbstractProjet {
@ElementCollection
@Enumerated(EnumType.STRING)
@JoinTable(uniqueConstraints = {
@UniqueConstraint(columnNames = { "projetdiffusion_id", "technologies" }) })
private List<ProjetTechnologie> technologies =
Lists.newArrayList();
Before the upgrade to 5, the join table was called
projetdiffusion_technologies and the column was projetdiffusion_id.
After the upgrade to 5, the join table is called
abstractprojet_technologies and the column abstractprojet_id. Thus, we have
an error on the creation of the unique constraint.
Is this change expected?
--
Guillaume
7 years, 3 months
