Re: [hibernate-dev] Add entity with InheritanceType.JOINED to native query

[Yoann Rodiere]

Hi,

I'll let it to actual Hibernate ORM developers (which I'm not) to give you
a proper answer (if they have one), but this seems like a bug to me. You
best course of action may be to provide a test case and provide it as part
of a ticket on JIRA: https://hibernate.atlassian.net/ .

If you really are in a hurry and can't wait for this to be fixed...
My previous team had to work this around in one of our projects once, and
we ultimately resorted to some ugly hack that would rely on the fact that
Hibernate generates semi-deterministic aliases for JOINed tables. I don't
remember the specifics, but this definitely involved guessing
Hibernate-generated aliases.
For instance, if "s" is your main table alias, Hibernate will use something
like "s_1_" for the table mapped to the first child class, "s_2_" for the
second child class, and so on. You can then try guessing the aliases and
make use of them in your JOIN clause instead of your custom alias ("{a}"),
being careful to remove the braces. The order seems to be stable for each
subsequent execution, but has been seen to change when doing major code
updates (though I couldn't say which).
As I said, this is ugly. It may do for non-essential, well-tested code that
won't have to evolve much, but this isn't necessarily your case.

Yoann

On 7 September 2016 at 03:41, Jan-Willem Gmelig Meyling <
jan-wil...@youngmediaexperts.nl> wrote:

> Hi Hibernate developers,
>
> I stumbled upon an issue today and I am wondering whether the following
> would be possible using Hibernate, and if not, whether such could actually
> be implemented, or if I actually hit a boundary of the alias injection.
>
> My problem has to do with trying to map the result set of a native query
> to an entity that uses the JOINED InheritanceType. After adding the enitity
> to my NativeQuery as follows, the aliases for the tables of the subclasses
> are not set properly (obviously). My question is, though, would it be
> possible to set these as well? As I can’t figure this out from the current
> documentation (that only states that all columns should be present in the
> result set, which I assume to apply to a InheritanceType.SINGLE_TABLE
> primarily).
>
> The code I am currently using to construct the query is as follows:
>
>
> session
>.createNativeQuery("SELECT {s.*} FROM my_super {s} LEFT JOIN my_sub_a
> {a} USING (id)")
>.addEntity("s", MySuper.class)
>.getSingleResult();
>
> Additional code is available on Github gist: https://gist.github.com/
> JWGmeligMeyling/51e8a305f3c268eda473511e202f76e8
>
> And my question is also posted on Stackoverflow (to gain some extra
> credits for the answer ;-) ):
> http://stackoverflow.com/questions/39359924/add-entity-
> with-inheritancetype-joined-to-native-query
>
> Thanks in advance,
>
> Jan-Willem
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] OpenJDK proposal: JDK 9 modules and reflection

[Yoann Rodiere]

I'll try to jump in. I'm mainly providing an external point of view though,
since I didn't seriously follow the progress of Java 9.

If I understood correctly, modules containing entities would not need to be
weak; they *could* be, as a quick solution to migrating to Java 9, but
ultimately the clean way of (re-)writing them would be:

module foo.bar {
exports private com.foo.bar.model; // Exports to anyone, including
hibernate.*
requires javax.jpa;
}

(Assuming all classes needed by Hibernate are in `com.foo.bar.model`)

Then public classes of package `com.foo.bar.model` would be exported to any
module, and additionally package-protected classes from this package could
be made accessible by anyone using `AccessibleObject::setAccessible`. Which
seems to solve the issue at least in principle.

What I'm not sure about is if it couldn't be even stricter by using a
qualified export :

module foo.bar {
exports private com.foo.bar.model to hibernate.entitymanager;
exports private com.foo.bar.model to hibernate.core;
requires javax.jpa;
}

It has the advantage of not disclosing private code to the entire world,
but the disadvantage of referring to the JPA implementation explicitely,
which is a shame.

In an ideal world, it would be awesome to be able to not reference
Hibernate at all (as below) and still reduce the visibility of the
"private" package to only a select few modules. It doesn't seem to be
possible, and I guess the syntax below is wrong for many reasons. Not the
least being that there's no way for the JVM to connect the dots between JPA
and Hibernate.

module foo.bar {
exports private com.foo.bar.model to javax.jpa; // Won't work
requires javax.jpa;
}

In the end, isn't the issue also about the lack of a concept of "module
interface", which "implementation modules" may implement? I mean, here, a
developer may not want to say "I'm using Hibernate", just "I'm using JPA",
and let the consumer of the module choose the actual JPA implementation. It
would be a bit like the `uses` and `provides` keywords, except we would be
referring to entire modules instead of classes.
I guess that, of course, the full definition of such a feature might get
quite complex depending on what it provides exactly.

Yoann Rodière 
Hibernate NoORM Team

On 16 September 2016 at 19:27, Emmanuel Bernard 
wrote:

> No one ?
>
> > On 13 Sep 2016, at 10:19, Emmanuel Bernard 
> wrote:
> >
> > Hi all,
> >
> > Sanne kindly pointed out to me the latest proposal by the OpenJDK team
> > around JDK 9 module and how they would handle frameworks needing access
> > to non exported types (Hibernate, dependency injection, etc).
> >
> > If you are remotely into JDK9, please read it and provide feedback.
> > http://mail.openjdk.java.net/pipermail/jpms-spec-experts/
> 2016-September/000390.html
> >
> > It's better than before for sure. It feels to me that most applications
> > (the core of it) will end up being a weak module for this to work
> > though. I'm not sure whether it is good or bad, at least a isolation
> > concious person has the choice.
> >
> >export private some.package;
> >
> > Is essentially equivalent to what you can do for a given package in Java
> > 8.
> > What I am less clear about is what relation Hibernate * projects really
> > need with a module containing the entities. Do we still this proposal
> > still mandates to use
> >
> >requires hibernate.entitymanager;
> >requires hibernate.core;
> >
> > in the targeted module?
> >
> > Or would this be a usable module
> >
> >module foo.bar {
> >exports private com.foo.bar.model;
> >requires javax.jpa;
> >// requires hibernate.entitymanager/core; no longer needed thanks
> to export private?
> >}
> >
> > Mark proposes that in a container (EE or anything controlling module
> loading
> > really), the container adds dynamically the addExports to the relevant
> > framework. But that looks like a solution to limit exports private
> > implications.
> >
> > Comments?
> >
> > Emmanuel
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [OGM] Issue with a test and the new operation grouping infrastructure

[Yoann Rodiere]

(Don't know what's the status of this, since it's been discussed on IRC,
but jumping in just in case)

I tend to agree with Gunnar that storing the association on the owning side
of the association seems like a good idea. At least with an external point
of view, it seems like the right choice, but I may be missing some details.

As for the specifics of the implementation, I just stumbled upon
`org.hibernate.ogm.persister.impl.BiDirectionalAssociationHelper`.
`getInverseCollectionPersister(OgmCollectionPersister)` and
`getInverseAssociationKeyMetadata(OgmEntityPersister, int)` may help... ?
All these methods suffer from a limitation: the current implementation will
only work with non-inverse collection persisters. **But** I wonder if it's
a limitation of the current implementation (we can't do more) or an
arbitrary limitation added on purpose (we don't want to do more).
For instance, in `getInverseCollectionPersister(OgmCollectionPersister)`,
we might think that the element persister used to get the reverse side is
null for inverse association. But from what I see in
`org.hibernate.persister.collection.AbstractCollectionPersister.AbstractCollectionPersister(Collection,
CollectionRegionAccessStrategy, PersisterCreationContext)` (line 315), the
element persister is always non-null regardless of whether the collection
persister is on the owning or the inverse side, provided it's not an
`@ElementCollection`.
Anyway, what I'm trying to say is:
`org.hibernate.ogm.persister.impl.BiDirectionalAssociationHelper` might not
help as it is now, but it's probably a good starting point.


Yoann Rodière 
Hibernate NoORM Team

On 12 September 2016 at 17:31, Guillaume Smet 
wrote:

> Hi,
>
> This is a follow-up of https://github.com/hibernate/hibernate-ogm/pull/767
> .
>
> So, in the PR, I commented the following test:
> ManyToOneGlobalTest>ManyToOneTest.testRemovalOfTransientEntityWi
> thAssociation
> (the "ManyToOneGlobalTest>" part is important)
>
> The test is a Redis one but the issue is a general one.
>
> When running under the ManyToOneGlobalTest umbrella, the associations
> are created as separate documents.
>
> The behavior of the test is the following:
>
> 
>
> === Creation phase
>
> Create a SalesForce with 2 SalesGuys associated.
>
> The association is managed by SalesGuy.
>
> It creates 4 documents:
> SalesForce1
> SalesGuy1
> SalesGuy2
> SalesForce1_SalesGuy navigational information
>
> === Let's delete the SalesForce1 entity
>
> It removes the SalesForce1 document (note that SalesGuy.salesForce has
> a @NotFound(action = NotFoundAction.IGNORE) annotation).
>
> So we end up with having:
> SalesGuy1
> SalesGuy2
> SalesForce1_SalesGuy navigational information [1]
>
> === Then we delete the 2 SalesGuy
>
> SalesGuys1 removed
> -> SalesForce_SalesGuy navigational information updated
> SalesGuy2 removed
> -> SalesForce1_SalesGuy navigational information removed as it is empty [2]
>
> 
>
> In [1], we still have the navigational information for SalesForce1 <->
> SalesGuys.
>
> With the new grouping infrastructure, I don't save every operation to
> the datastore as it's currently done. I have to store the Association
> object somewhere to keep track of the association state so I store it
> in OgmEntityEntryState in a Map, the key being
> the role of the association, just next to the Tuple which has the same
> purpose. It works perfectly well except that when we arrive at [2],
> the OgmEntityEntryState for SalesForce1 is gone as the entity has been
> removed in [1] so I can't access the OgmEntityEntryState of the entity
> and so the association document is not removed (and thus the test
> fails as it checks there isn't any entity/association left).
>
> Gunnar proposed the idea of storing the inverse Associations in the
> OgmEntityEntryState of the association owner. It's indeed one way to
> solve the issue.
>
> The issue with this approach is that we need to have the association
> owner when we create the AssociationPersister and, while it's not a
> problem for most of the cases, I don't see how I can do it in
> OgmLoader#getResultSet. I posted a WIP patch here:
> https://gist.github.com/gsmet/e18ccb7d3f3494bb334647e540d0d4d0.
>
> Opinions, thoughts?
>
> --
> Guillaume
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] HSEARCH-2358 "fields" attribute in Elasticsearch search results is being ignored

[Yoann Rodiere]

Hi,

I wanted to start a discussion about this issue.

It's about stored field retrieval. When searching, Elasticsearch can return
field values two different ways:

 * through the "_source" attribute [1], which basically provides a
copy-paste of the JSON that was submitted when indexing
 * or through the "fields" attribute [2], which only works for stored
fields and provides the actual value that Elasticsearch stored

The main difference really boils down to formatting. With the "_source"
attribute, there's no formatting involved, you get exactly what was
originally submitted. With the "fields" attribute, the value is formatted
according to the first format in the mapping's format list [3].

The thing is, Elasticsearch allows admins to set multiple formats for a
given field. This won't change the output format, but will allow using any
one of these formats when submitting information. Since these "extra"
formats probably aren't understood by Hibernate Search, this means that
using the "_source" attribute to retrieve field values becomes unreliable
as soon as someone else adds/changes documents in Elasticsearch...

So we have two solutions:

 1. Either we only use the "fields" attribute to retrieve field values, and
we force users to have the output format set to something HSearch will
understand, but allow extra input formats.
 2. or we use the "_source" attribute to retrieve field values, and then we
force both output and input format on users, and do not allow extra formats.

I'd be in favor of 1, which seems more rational to me. It only has one
downside: if we go on with this approach, Calendar values (and
ZonedDateTime, ZonedTime, etc.) will have to be stored as String, not as
Date, since Elasticsearch doesn't store the timezone, just the UTC
timestamp. We're currently working this around by inspecting the "_source",
which contains the original timezone (since it's just the raw, originally
submitted JSON).

What do you think?

[1]
https://www.elastic.co/guide/en/elasticsearch/reference/current/mapping-source-field.html
[2]
https://www.elastic.co/guide/en/elasticsearch/reference/current/search-request-fields.html
[3]
https://www.elastic.co/guide/en/elasticsearch/reference/2.4/mapping-date-format.html#custom-date-formats

Yoann Rodière 
Hibernate NoORM Team
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] HSEARCH-2358 "fields" attribute in Elasticsearch search results is being ignored

[Yoann Rodiere]

On 28 September 2016 at 15:23, Guillaume Smet 
wrote:
>
> You won't be able to use these sorts of features:
> https://www.elastic.co/guide/en/elasticsearch/reference/curr
> ent/search-aggregations-bucket-datehistogram-aggregation.html
> https://www.elastic.co/guide/en/elasticsearch/reference/curr
> ent/search-aggregations-bucket-daterange-aggregation.html
> which are used very often when dealing with dates.
>
> I don't think storing dates as strings is a viable alternative.
>

Right. I didn't know about these.


> IMHO, the choice is between:
> - using _source as we currently do it. I'm not sure allowing people to
> directly inject data into Elasticsearch and bypass Hibernate Search is
> something we can support in the long run so I think it would be acceptable
> if we document that we don't expect people to index documents directly (or
> at least that they should carefully follow the HS indexing format - which
> looks like an acceptable thing).
> - using fields and be aware that we will get back UTC values from
> projections on these fields
>

... and the latter is a no-go for ZonedDate et al., since the point of
those classes is to preserve timezone/offset.
Maybe we could just use "_source" when we really need to, but I doubt
there's an elegant way to do this, so I guess we'd better not.

Anyway, it seems we're down to only one acceptable solution... Unless
anyone has another view on all this, I'll index ZonedDate/etc. as dates and
use "_source" for value retrieval, and I'll close HSEARCH-2358 as "Won't
fix".

Thanks for the insight!

Yoann Rodière 
Hibernate NoORM Team
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [OGM] Neo4j integration dependencies

[Yoann Rodiere]

Is there any particular reason why we would not want to create three
artifacts, besides backward compatibility? It seems the obvious and ideal
solution, but I might be missing something.

If there is common code, we can always create a fourth -neo4j-core artifact
that would have no interest to users but would simply ensure we don't
duplicate code, and would be delivered through transitive dependencies.

About backward compatibility, I guess there are two options:

   - If the last released version of the artifact used to contain only the
   embedded mode, we can use maven relocation
   - Otherwise, we can advertise this artifact as deprecated, remove almost
   everything in it and add the relevant new artifacts as dependencies.

Or am I being too naive?

Yoann Rodière 
Hibernate NoORM Team

On 19 October 2016 at 11:17, Davide D'Alto  wrote:

> The integration with Neo4j in OGM makes it possible for a user to
> select the strategy that he wants to use to connect to an embedded or
> remote Neo4j instance.
> There are 3 possible options:
> 1) Embedded mode, Neo4j run in the same JVM
> 2) Remote via HTTP interface using RestEasy
> 3) Remote via the Bolt protocol using the neo4j-java-driver library
>
> Everything is now in one single artifact meaning that for each case we
> have more dependencies than needed, in particular for the remote
> cases.
>
> Possible solutions I can think of at the moment are:
>
> 1) Have different maven artifacts:
> - We could have 3 artifacts: EMBEDDED, HTTP and BOLT
> - or 2 artifacts: EMBEDDED and REMOTE: This won't completely solve
> the issue because w would still have
>   resteasy (for HTTP) and neo4j-java-driver (for BOLT) but it
> might be a good trade-off
>
> We will need to share some resource so this approach might require
> a Neo4j common library.
>
> 2) Make some dependencies optional (Need to test this, but it might work)
>
> 3) Use some maven plugin to generate different artifacts from the same
> module. I haven't used this approach before so I'm not sure if it is
> feasible.
>
> 4) ???
>
> Any opinion about this?
>
> Issue on JIRA: https://hibernate.atlassian.net/browse/OGM-1190
>
> Thanks,
> Davide
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [OGM] Neo4j integration dependencies

[Yoann Rodiere]

On 21 October 2016 at 12:20, Guillaume Smet 
wrote:

> I always prefer to migrate early to the right solution when there is a
> compelling reason to do so and a clear logic in it.


I totally agree with that, but I think it's more about what we promised to
users than about what we think is the best practice they should follow.
For APIs, we probably promised backward compatibility across minor
versions. Even if we didn't explicitly promise this, doing otherwise would
probably upset users.
As to maven coordinates, that's kind of a grey area... I guess that, given
users have to change their maven coordinates (the version) when
upgrading anyway, the breaking artifact ID change may not be that bad. A
bit surprising, but not really harmful.

Yoann Rodière 
Hibernate NoORM Team
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate Search and Elasticsearch 5 support

[Yoann Rodiere]

Hello,

I just finished assessing the required changes for supporting Elasticsearch
5.0. I put the details in this ticket:
https://hibernate.atlassian.net/browse/HSEARCH-2434

Here is a quick summary:

   - Some (non-breaking) changes are required in Jest [1]
   - We'll have to update the way we do integration testing:
   elasticsearch-maven-plugin doesn't work well with ES 5.0 and will require a
   major overhaul to work. [2]
   - There are some breaking changes that require us either drop support
   for ES 2.x or introduce dialects (for instance the string datatype has been
   split into two datatypes: text and keyword, which behave quite differently).
   - And, perhaps most importantly, support for defining analyzers in
   elasticsearch.yml has been dropped. This means users have to resort to the
   index settings API to define their analyzers. So this breaks our automatic
   index creation / mapping generation feature: we put mappings just after
   creating the index, but since the index was just created analyzer
   definitions will be missing and the mapping will be rejected. See
   HSEARCH-2434 (in the comments) for details.

Ultimately, what we have to decide is how and when we're going to support
ES 5. Several options have already been mentioned on HipChat:

   1. Support ES 5.x right now and drop support for ES 2.x
   2. Support both ES 5.x and 2.x right now by introducing dialects (that
   could be chosen automatically by asking the running version to the server)
   3. Only support ES 2.x for now and keep ES 5.x for later (probably HS
   6.0)

We have to consider several things in order to make the decision:

   - Deadlines and available resources. Supporting 5.x only should be easy
   enough, I think (if we ignore the analyzer definition issue) ; actually I
   already did some work [3]. The dialect solution would obviously require
   some more work, but if only target a quick, dirty fix (to be refactored in
   6.0) it shouldn't be hell.
   - Users. Dropping support for 2.x probably will make someone angry. But
   then, we only published alpha/betas and advertised experimental support for
   now, so there's shouldn't be many people using it in a production
   environment.


Thoughts, opinions?


[1] https://github.com/searchbox-io/Jest/pull/408
[2] https://github.com/alexcojocaru/elasticsearch-maven-plugin/pull/19
[3] https://github.com/yrodiere/hibernate-search/tree/HSEARCH-2434


Yoann Rodière 
Hibernate NoORM Team
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Hibernate Search and Elasticsearch 5 support

[Yoann Rodiere]

On 2 November 2016 at 12:59, Guillaume Smet 
wrote:

> The other important point (mentioned in the issue but I think it's
> important to outline it here) concerning the analyzers is that they are now
> defined per index: there are no global analyzers, you have to define them
> for every index using the analyzer. It is totally different from our
> current approach and make defining them manually (and maintaining them)
> even more cumbersome. Thus I don't think we can consider defining them
> manually as an option.
>

Yes, and that's the reason our automatic mapping generation is broken.
Since the scope of analyzers is now the index, posting analyzer definitions
should take place after index creation. But it should also happen before
mappings are put in the index (since they reference analyzers). In
practice, that means we must have users create indexes themselves (which
can't be done in bulk, which is cumbersome) and post analyzer definitions
themselves (which can be done in bulk and is relatively easy).

On 2 November 2016 at 12:59, Guillaume Smet 
 wrote:

> If we want to support Es 5, we need to provide a way to define these
> analyzers in HS and make HS post them to Es.
>
Agreed: once we automate posting analyzer definitions to Elasticsearch from
HS, the actual API used to create indexes or post analyzers and its
"cumbersomeness" become irrelevant.
Our options are:

   - Using the existing annotations and try as best we can to translate
   Lucene analyzers to their name and parameters in ES: it won't help when
   using non-Lucene analyzers, and it feels like something we can't maintain
   forever.
   - Introducing a new analyzer definition API: is it the right time, with
   HS 6.0 looming over the horizon?
   - Using the simple JSON file solution I proposed. Ok, maybe
*simplistic* rather
   than *simple*, but it'd be easy to implement and probably wouldn't
   require much maintenance work if we decide to keep it in 6.0.


Yoann Rodière 
Hibernate NoORM Team
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] [Hibernate Search] Added a test utility to assert produced log

[Yoann Rodiere]

Hi team,

Just so you know, if you ever need to assert that a certain log is produced
in your JUnit tests, there's now a tool to do just that in Hibernate
Search: org.hibernate.search.test.util.impl.ExpectedLog4jLog [1]

You may use it much like you would use the ExpectedException rule:

public class MyTest {
@org.junit.Rule
public ExpectedLog4jLog logged = ExpectedLog4jLog.create();

@Test
public void test() {
logged.expectMessage( "HSEARCH400032", "some substring I want in the same
log" );

// ... Do test ...
}
}

You can also assert more complex conditions on the logs, using
a org.hamcrest.Matcher, but then it's starting to
get a bit exotic.

You may find an example of real-life use at [2].

[1]
https://github.com/hibernate/hibernate-search/blob/master/engine/src/test/java/org/hibernate/search/test/util/impl/ExpectedLog4jLog.java
[2]
https://github.com/hibernate/hibernate-search/blob/master/elasticsearch/src/test/java/org/hibernate/search/elasticsearch/test/ElasticsearchUnsupportedFeaturesIT.java

Cheers,

Yoann Rodière 
Hibernate NoORM Team
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Use @AssociationOverride with @MapKeyJoinColumn

[Yoann Rodiere]

Hi,

I just ran the test case, and there's something odd indeed: as Florian
said, @MapKeyJoinColumn in embeddables seem to be completely ignored when
the (embedded) association is overridden using @AssociationOverride. When
not using @AssociationOverride, everything works fine.

Vlad, do you think this could be a bug? It seems odd, but maybe I'm missing
something.

I forked the test to make it run on an embedded H2 instance, which should
be easier to run quickly: https://github.com/yrodiere/hibernate-test-case

Yoann Rodière 
Hibernate NoORM Team

On 23 November 2016 at 17:09, Florian Lacreuse 
wrote:

> We didn't know about the JPA spec on this particular detail, thanks for
> the precision.
>
> Nonetheless, we don't want to override the @MapKeyJoinColumn, we just
> want the annotation to be taken into consideration while we use
> @AssociationOverride to override something else.
>
> We have updated the test case
> (https://github.com/florianlacreuse/hibernate-test-case
> ). In Employee
> entity we use the same embeddable twice, so we have to use
> @AssociationOverride to name the two join tables. In both tables, the
> column related to the key has the default name ("experiences_KEY")
> instead of the one provided by the @MapKeyJoinColumn ("jobtitle_id").
>
> To resume, we understrand that it's not possible to override
> @MapKeyJoinColumn but @MapKeyJoinColumn should not be ignored.
>
> In Employee entity you can also find a third attribute with the same
> embeddable but without any @AssociationOverride. In this case,
> @MapKeyJoinColumn works as expected.
>
> Kind regards,
>
> Logo 
>
> 151 boulevard Stalingrad
> 69100 Villeurbanne
> www.smile.fr 
> *Florian LACREUSE*
> Ingénieur d'études et développement
> Pôle Développement Spécifique Java
> Open Wide - Systèmes d'Information
> Email : florian.lacre...@smile.fr 
>
>
> Le 23/11/2016 à 16:08, Vlad Mihalcea a écrit :
> > The JPA spec does not specify a way to override the MapKeyJoinColumn.
> > You can override the association, like the JoinColumn for a ManyToOne
> > or a JoinTable for OneToMany.
> >
> > In your case, maybe it's better to move that association out of the
> > embeddable.
> > It's always a good idea to keep the model as simple as possible.
> >
> > Vlad
> >
> > On Wed, Nov 23, 2016 at 4:10 PM, Florian Lacreuse
> > mailto:florian.lacre...@smile.fr>> wrote:
> >
> > Hi,
> >
> > We have a problem using @AssociationOverride and @MapKeyJoinColumn
> and
> > we would like to have your opinion about this to know if this is
> > an issue.
> >
> > Here is the test case :
> > https://github.com/florianlacreuse/hibernate-test-case
> > 
> >
> > Short explanation about the model : an entity with an embeddable
> field
> > wrapping a map with an entity as key and a basic type as value.
> >
> > We use @AssociationOverride to rename the join table (annotation on
> > embeddable field) and @MapKeyJoinColumn to rename the column
> > related to
> > the key map (annotation on map field).
> >
> > Unfortunately, it would seem that the @MapKeyJoinColumn annotation is
> > ignored. @AssociationOverride may override any other annotations
> > on the
> > map field ? In this case how to rename the column related to the
> > key map
> > with the @AssociationOverride ?
> >
> > Is this an issue or is there any trick we don't know about?
> >
> > Thanks for your help.
> >
> > Kind regards,
> >
> >
> > Logo 
> >
> > 151 boulevard Stalingrad
> > 69100 Villeurbanne
> > www.smile.fr  
> > *Florian LACREUSE*
> > Ingénieur d'études et développement
> > Pôle Développement Spécifique Java
> > Open Wide - Systèmes d'Information
> > Email : florian.lacre...@smile.fr
> > 
> >  >>
> >
> >
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org 
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > 
> >
> >
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate Search 5.6.0.Beta4 and 5.7.0.Beta1 released

[Yoann Rodiere]

Hello everyone,

We just released Hibernate Search 5.6.0.Beta4 and 5.7.0.Beta1, with the
latest bugfixes and previously missing features for our experimental
Elasticsearch integration.

For more information, please see our blog:

http://in.relation.to/2016/11/29/hibernate-search-5-6-0-Beta4-and-5-7-0-Beta1/

Have a nice day,

Yoann Rodière 
Hibernate NoORM Team
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] [SEARCH] Translating analyzer definitions from HSearch to Elasticsearch

[Yoann Rodiere]

Hello everyone,

I'm currently working on HSEARCH-2219, "Define analyzers via the REST API",
whose purpose is to automatically translate @AnalyzerDefs in Hibernate
Search to settings in Elasticsearch, removing the need for users to
configure analyzers separately in their Elasticsearch instance.

The thing is, the structure of our configuration in Hibernate Search is
different from the one in Elasticsearch. In particular, we can't name
instances of token filters, char filters, etc, while in Elasticsearch one
*has* to name them in order to provide parameters.

See for instance:

@AnalyzerDef(
  name = "myAnalyzer",
  tokenizer = @TokenizerDef(
factory = StandardTokenizerFactory.class,
parameters = @Parameters(@Parameter(name = "maxTokenLength", value =
"900"))
  )
)

compared to the Elasticsearch way:

index :
analysis :
analyzer :
myAnalyzer :
type : custom
tokenizer : myTokenizer1
tokenizer :
myTokenizer1 :
type : standard
max_token_length : 900

The analyzer name is there on both sides, @TokenizerDef.factory would give
me the tokenizer type, and parameters are pretty obvious too. But
"myTokenizer1", the tokenizer name, has absolutely no equivalent in
Hibernate Search.

I could try to generate names automatically, but those would need to be
more or less stable across multiple executions in order for schema
validation to work properly. And there's nothing we could really use as an
identifier in our annotations, at least not reliably.

To fill the gap, I'd like to add a "name" attribute to the TokenizerDef,
CharFilterDef and TokenFilterDef annotations. This attribute would be
optional and the documentation would mention that it's useless for embedded
Lucene.

Another solution would be to have a "magic" @Parameter, named after a
constant (ElasticsearchParameters.TOKENIZER_NAME for instance), and detect
that parameter automatically, but it feels wrong... mainly because
@AnalyzerDef already has its own "name" attribute, so why wouldn't
@TokenizerDef?

And finally, we could bring our annotations closer to the Elasticsearch
way, by providing a way to define tokenizers/char filters/token filters and
a separate way to reference those definitions, but I don't think that's 5.6
material, since we'd likely have to break things or lose consistency.

WDYT?

Yoann Rodière 
Hibernate NoORM Team
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate Search 5.6.0.CR1 and 5.7.0.Beta2 released

[Yoann Rodiere]

Hello everyone,

We just released Hibernate Search 5.6.0.CR1 and 5.7.0.Beta2, with the
latest bugfixes and previously missing features for our experimental
Elasticsearch integration.

This is the last step before 5.6 is released, so be sure to check it out so
you can share your thoughts with us before the release!

For more information, please see our blog:

http://in.relation.to/2016/12/20/hibernate-search-5-6-0-CR1-and-5-7-0-Beta2/

Cheers,

Yoann Rodière 
Hibernate NoORM Team
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] ScrollableResults and 6.0

[Yoann Rodiere]

For what it's worth, changing the signature indeed seems appropriate to me:
the fewer object arrays, the better.
Your proposal would require making Query parameterized too, though. I'm not
really up-to-date with the current state of 6.0, but I guess it's already
done or being done.

Anyway, the only think I wanted to say was: if we break the API, maybe we
should try to make sure we won't have to break it again soon. There has
been some discussions about adding scrolling to the JPA spec:
https://java.net/jira/browse/JPA_SPEC-89 . Maybe it would be worth it to
ask for advice on this ticket, so as to limit the risk of having to break
this API again, because the spec would introduce an incompatible signature?
Not sure there would be many reactions, judging by the low activity on the
ticket, but who knows...

Yoann Rodière 
Hibernate NoORM Team

On 27 December 2016 at 22:02, Steve Ebersole  wrote:

> FWIW my inclination is to just change the existing signatures.  6.0 is a
> major release with major changes already wrt querying.
>
>
> On Tue, Dec 27, 2016 at 3:01 PM Steve Ebersole 
> wrote:
>
> > For 6.0 I'd like to also make ScrollableResults parameterized wrt the
> "row
> > type".  E.g.
> >
> > ScrollableResults sr = session.createQuery( ..., Person.class
> > ).scroll();
> >
> > However that changes the signature of its methods returning a "row"
> > (currently always defined as Object[]).
> >
> > How would everyone prefer we handle this?  Do I just change the
> signatures
> > of the existing methods?  Or add new methods?
> >
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] ScrollableResults and 6.0

[Yoann Rodiere]

> Regarding JPA adopting scrolling as a feature, what I suggest simply
follows what Hibernate ans JPA already do for other Query returns.  Today
it is completely inconsistent between Query#scroll and Query#list e.g..  I
am just suggesting making that consistent.

Sure. I just wanted to point out that scrolling isn't part of JPA yet, but
there are plans to add it, so we might as well try to know what form it
will take in JPA 2.2 in order to make the change future-proof.

To be perfectly clear: it was just a heads-up because I came accross this
JPA ticket a few weeks ago, I don't have any specific concern in mind. If
you think it's not relevant, sorry for the noise.


Yoann Rodière 
Hibernate NoORM Team

On 2 January 2017 at 12:42, Steve Ebersole  wrote:

> org.hibernate.query.Query extends javax.persistence.TypedQuery since 5.2,
> so it already has been parameterized.
>
> Regarding JPA adopting scrolling as a feature, what I suggest simply
> follows what Hibernate ans JPA already do for other Query returns.  Today
> it is completely inconsistent between Query#scroll and Query#list e.g..  I
> am just suggesting making that consistent.
>
> On Mon, Jan 2, 2017 at 2:36 AM Yoann Rodiere  wrote:
>
>> For what it's worth, changing the signature indeed seems appropriate to
>> me: the fewer object arrays, the better.
>> Your proposal would require making Query parameterized too, though. I'm
>> not really up-to-date with the current state of 6.0, but I guess it's
>> already done or being done.
>>
>> Anyway, the only think I wanted to say was: if we break the API, maybe we
>> should try to make sure we won't have to break it again soon. There has
>> been some discussions about adding scrolling to the JPA spec:
>> https://java.net/jira/browse/JPA_SPEC-89 . Maybe it would be worth it to
>> ask for advice on this ticket, so as to limit the risk of having to break
>> this API again, because the spec would introduce an incompatible signature?
>> Not sure there would be many reactions, judging by the low activity on
>> the ticket, but who knows...
>>
>> Yoann Rodière 
>> Hibernate NoORM Team
>>
>> On 27 December 2016 at 22:02, Steve Ebersole  wrote:
>>
>> FWIW my inclination is to just change the existing signatures.  6.0 is a
>> major release with major changes already wrt querying.
>>
>>
>>
>> On Tue, Dec 27, 2016 at 3:01 PM Steve Ebersole 
>> wrote:
>>
>> > For 6.0 I'd like to also make ScrollableResults parameterized wrt the
>> "row
>> > type".  E.g.
>> >
>> > ScrollableResults sr = session.createQuery( ..., Person.class
>> > ).scroll();
>> >
>> > However that changes the signature of its methods returning a "row"
>> > (currently always defined as Object[]).
>> >
>> > How would everyone prefer we handle this?  Do I just change the
>> signatures
>> > of the existing methods?  Or add new methods?
>> >
>>
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
>>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] CI Jenkins upgraded to version 2.38

[Yoann Rodiere]

Thanks! Looking forward to using pipelines :)

It seems PR jobs for Hibernate Search do not trigger anymore, though:

 * https://github.com/hibernate/hibernate-search/pull/1273 was submitted
yesterday
 * there is no build on http://ci.hibernate.org/view/Pull%20Requests/job/
hibernate-search-PR/ since december 23
 * and I tried to restart the build explicitly from the PR, with no luck

It's a bit odd, because the OGM PR job seems to work fine... From what I
can see there hasn't been any particular change on the OGM job.

I can't look at the trigger options on GitHub (I lack the access rights),
but maybe the difference between OGM and Search lies there?

Anyway... I'm going for today, maybe I'll see something obvious tomorrow
morning!

Cheers,

Yoann Rodière 
Hibernate NoORM Team

On 3 January 2017 at 18:22, Yoann Rodiere  wrote:

> Thanks! Looking forward to using pipelines :)
>
> It seems PR jobs for Hibernate Search do not trigger anymore, though:
>
>  * https://github.com/hibernate/hibernate-search/pull/1273 was submitted
> yesterday
>  * there is no build on http://ci.hibernate.org/view/Pull%20Requests/job/
> hibernate-search-PR/ since december 23
>  * and I tried to restart the build explicitly from the PR, with no luck
>
> It's a bit odd, because the OGM PR job seems to work fine... From what I
> can see there hasn't been any particular change on the OGM job.
>
> I can't look at the trigger options on GitHub (I lack the access rights),
> but maybe the difference between OGM and Search lies there?
>
> Anyway... I'm going for today, maybe I'll see something obvious tomorrow
> morning!
>
> Cheers,
>
> Yoann Rodière 
> Software Engineer
> Red Hat / Hibernate NoORM Team
>
> On 3 January 2017 at 13:31, Davide D'Alto  wrote:
>
>> Thanks for the feedback,
>>
>> header and footer should be fine now.
>>
>> Thanks,
>> Davide
>>
>> On Thu, Dec 29, 2016 at 11:37 PM, Sanne Grinovero 
>> wrote:
>> > Thanks Davide!
>> > The builds seems to work just fine, the only minor defect I've noticed
>> > is with the stylesheet doing some strange things when scrolling down:
>> > the breadcrumbs will "float" down as well. Definitely not urgent,
>> > great to have all updates!
>> >
>> > Thanks,
>> > Sanne
>> >
>> >
>> > On 28 December 2016 at 01:04, Davide D'Alto 
>> wrote:
>> >> Hi,
>> >> I hope you all had great holidays.
>> >>
>> >> I've upgraded our Jenkin on CI to version 2.38.
>> >>
>> >> As far as i can tell everything seems all right, but if you experience
>> >> some unusual problems,
>> >> please, let me know.
>> >>
>> >>
>> >> Cheers,
>> >> Davide
>> >> ___
>> >> hibernate-dev mailing list
>> >> hibernate-dev@lists.jboss.org
>> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] [SEARCH] Query-only analyzers with Elasticsearch - new annotation?

[Yoann Rodiere]

Hello team,

I'm currently working on HSEARCH-2534, "Query-only analyzer definitions are
never added to the index settings with Elasticsearch".
This issue is about using analyzers only when querying with Elasticsearch.
It is already possible with Lucene, but not in Elasticsearch, because we
assume that any analyzer definition that is not referenced by a @Analyzer
annotation is a Lucene analyzer [1].

To be precise, the exact place where query-only analyzers are used is in
EntityContext.overridesForField [2], and the overrides are leveraged even
with Elasticsearch, for instance in ConnectedMultiFieldsTermQueryBuilder
[3].

I can see two solutions to the issue:

   1. Make all analyzer definitions available for all indexing services.
   2. Allow users to define, for each entity, which analyzer definitions
   will be necessary when querying, even though the definitions are not used
   when indexing.

Solution 1 seems quite hard to implement correctly.
First we'd have to have a different namespace for each indexing service,
but I've already implemented that much.
Second, some analyzer definitions are only valid for one indexing service,
and not for the other.
For instance, analyzer definitions using ElasticsearchTokenFilterFactory
are specific to Elasticsearch. And Analyzer definitions using
the WhitespaceTokenizerFactory with the "rule" parameter are only valid
with embedded Lucene. And so on. To sum up, I'm not sure we can do
something smart.

Solution 2 is easier to implement, but requires to add a bit of API: the
way for users to declare that a given analyzer definition is to be
available when querying a given entity. I would add type-level
@QueryAnalyzer(definition = "foo") and @QueryAnalyzers annotation.

I know nobody wants to add new annotations in a minor, but right now that
seems to be the only workable solution.

What do you think?

[1]
https://github.com/hibernate/hibernate-search/blob/1847bd222128395056cdf6e7cfb601ceed5e40c3/engine/src/main/java/org/hibernate/search/engine/impl/ConfigContext.java#L277
[2]
https://github.com/hibernate/hibernate-search/blob/1847bd222128395056cdf6e7cfb601ceed5e40c3/engine/src/main/java/org/hibernate/search/query/dsl/EntityContext.java#L14
[3]
https://github.com/hibernate/hibernate-search/blob/1847bd222128395056cdf6e7cfb601ceed5e40c3/engine/src/main/java/org/hibernate/search/query/dsl/impl/ConnectedMultiFieldsTermQueryBuilder.java#L222


Yoann Rodière 
Hibernate NoORM Team
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [SEARCH] Query-only analyzers with Elasticsearch - new annotation?

[Yoann Rodiere]

> I'm wondering how you'd all feel about the third solution:
> 3. don't do it.
> This depends of course how far it is blocking in practice.

"Don't do it until 6.0" would be acceptable, I guess, since it's still just
a technical preview. Though we would introduce a limitation that would only
be our fault (since Elasticsearch supports query-time analyzers) and that
would not exist with the Lucene integration.

"Don't do it ever" seems really bad. As we've already discussed at length
(multiple times), not being able to define analyzers from Hibernate Search
would be a real pain for users, especially in Elasticsearch 5. That's true
for indexing analyzers, and that's also true for querying-only analyzers.
I wouldn't say that query-only analyzers are widespread, but they're at
least useful, and I'm sure there are problems that can *only* be solved by
using a different analyzer when querying than when indexing...

> I guess that I'm missing why you'd want to force people to express
> that a specific Analyzer is meant to be used only at query time
> differently than one which is used at indexing time.
> If there is need to clearly make such discrimination then this should
> be made very clear to our users too, so I'd prefer if we could avoid
> introducing new concepts for people to learn.. unless there's strong
> need of course.

Analyzer definitions are interpreted as either Lucene analyzers (to be
instantiated) or Elasticsearch analyzers (to be pushed to the ES index
settings) based on where they are referenced (using @Analyzer).
When I say an analyzer definition is query-only, it means there is an
@AnalyzerDefinition but there isn't any @Analyzer referencing it. So
Hibernate Search wouldn't know how to interpret it (ES or Lucene).
Currently, the default for those definitions is to interpret them as Lucene
analyzers, which leads to HSEARCH-2534: we can't have Elasticsearch
query-only analyzers.

Maybe with this piece of information, my original message makes more sense?
I.e.:

   1. Solution 1, interpret those definitions as both Lucene and
   Elasticsearch analyzer (there are problems with that, see my first message)
   2. Solution 2, make users "reference" those definitions using a new
   @QueryAnalyzer annotation.

> Maybe I'm
> missing something, but couldn't a user simply use an additional
> @AnalyzerDef, so that the analyzer definition is associated to a name,
> and use that?

As mentioned above, an @AnalyzerDef that is not referenced is considered as
a Lucene analyzer, so it's not pushed to Elasticsearch and it can't be used
when querying Elasticsearch.
The only workaround I see would be to add a dummy, always-empty field like
that:

@Transient
@Field(name = "__dummy", analyzer = @Analyzer(definition =
"myQueryOnlyAnalyzer))
public String getMyQueryOnlyAnalyzerDummyField() {
  return null;
}

Which means there will be a useless field in the schema just to make
Hibernate Search happy.

> Is this issue relating to a specific user request?

No, it's just a feature that is available for Lucene but not for
Elasticsearch.


Yoann Rodière 
Hibernate NoORM Team

On 5 January 2017 at 13:04, Sanne Grinovero  wrote:

> Hello,
>
> I'm wondering how you'd all feel about the third solution:
>
>  3. don't do it.
>
> This depends of course how far it is blocking in practice. Maybe I'm
> missing something, but couldn't a user simply use an additional
> @AnalyzerDef, so that the analyzer definition is associated to a name,
> and use that?
>
> I guess that I'm missing why you'd want to force people to express
> that a specific Analyzer is meant to be used only at query time
> differently than one which is used at indexing time.
> If there is need to clearly make such discrimination then this should
> be made very clear to our users too, so I'd prefer if we could avoid
> introducing new concepts for people to learn.. unless there's strong
> need of course.
>
> Is this issue relating to a specific user request?
>
> Thanks,
> Sanne
>
>
>
> On 4 January 2017 at 16:00, Yoann Rodiere  wrote:
> > Hello team,
> >
> > I'm currently working on HSEARCH-2534, "Query-only analyzer definitions
> are
> > never added to the index settings with Elasticsearch".
> > This issue is about using analyzers only when querying with
> Elasticsearch.
> > It is already possible with Lucene, but not in Elasticsearch, because we
> > assume that any analyzer definition that is not referenced by a @Analyzer
> > annotation is a Lucene analyzer [1].
> >
> > To be precise, the exact place where query-only analyzers are used is in
> >

Re: [hibernate-dev] [SEARCH] Query-only analyzers with Elasticsearch - new annotation?

[Yoann Rodiere]

> I don't disagree, I'm merely aiming to have in future Analyzer(s)
> defined in a non-Lucene specific way, possibly allowing controlled
> exceptions.
> When changing the definitions API we'll be able to reconsider if we
> want Analyzer definitions to be scoped per index like Elasticsearch
> does.

Actually, for HSEARCH-2534, it would be enough if analyzer definitions were
scoped by indexing service (Lucene/ES).
But sure, that would be a good solution. If we wait for 6.0.

> Sure that wouldn't allow to map on Hibernate Search an existing ES
> cluster which uses conflicting names on different indexes, but reverse
> engineering of existing ES clusters isn't our focus at this time;
> people badly needing it can change their names to saner choices (as
> I'd argue that name reuse for different things wouldn't be a sane
> configuration, probably it won't be common either).

I agree with you on that. To be honest I didn't even think of such an
issue, since currently the analyzer definitions are scoped globally.

> is there something which prevents
> us to refine this decision and rather generate ES definitions out of
> all known Analyzer definitions, rather than just the ones being
> referred?

Well, yes, that was in my first message; see below:

> First we'd have to have a different namespace for each indexing service,
> but I've already implemented that much.
> Second, some analyzer definitions are only valid for one indexing service,
> and not for the other.
> For instance, analyzer definitions using ElasticsearchTokenFilterFactory
> are specific to Elasticsearch. And Analyzer definitions using the
> WhitespaceTokenizerFactory with the "rule" parameter are only valid with
> embedded Lucene. And so on. To sum up, I'm not sure we can do
> something smart.

What prevents us to generate ES definitions out of all known analyzer
definitions is that there may be definitions that *cannot* be translated to
ES, simply because they are supposed to be used only with Lucene.
I guess we could say "let's try to generate ES definitions, and if it fails
just ignore it and log a warning", but it seems a bit unsafe...

> Let's keep in mind that we're only able "translate" a very limited set
> of well-known Analyzer definitions [...]

For translations it's true, but any ES analyzer definition can be expressed
with Hibernate Search by using Elasticsearch*Factory. In fact, it's the
recommended approach.
See
https://docs.jboss.org/hibernate/search/5.6/reference/en-US/html_single/#_custom_analyzers
.

> In short, I think what matters most now is not how to define such
> analyzers as there are viable (better?) alternatives, but we need to
> make sure one can run a query with the right query-time overrides,
> especially be able to refer to an Analyzer which has been manually
> defined on ES but is possibly not known to us. (As discussed
> previously with the exception of More-Like-This Queries which will
> have to wait).

We already have discussed this many times, but once again: users will not
be able to define their analyzers manually on ES starting from ES 5.0 for
various reasons.
So that's clearly not a long-term solution. It's "viable" for now, but
since it's not future-proof it's certainly not better.

As for the short term, if I understand correctly, what you're proposing is
that users don't add an @AnalyzerDef for query-only analyzers, and that we
allow using unknown analyzers in queries? I guess we could do that, but
that basically amounts to solution 3 "don't do it". Which is fine as long
as we plan to fix it later.
Also note we'd still have to explain users that query-only analyzer
definitions are not supported with Elasticsearch.


Yoann Rodière 
Hibernate NoORM Team

On 5 January 2017 at 15:06, Sanne Grinovero  wrote:

> On 5 January 2017 at 13:06, Yoann Rodiere  wrote:
> >> I'm wondering how you'd all feel about the third solution:
> >> 3. don't do it.
> >> This depends of course how far it is blocking in practice.
> >
> > "Don't do it until 6.0" would be acceptable, I guess, since it's still
> just
> > a technical preview. Though we would introduce a limitation that would
> only
> > be our fault (since Elasticsearch supports query-time analyzers) and that
> > would not exist with the Lucene integration.
> >
> > "Don't do it ever" seems really bad. As we've already discussed at length
> > (multiple times), not being able to define analyzers from Hibernate
> Search
> > would be a real pain for users, especially in Elasticsearch 5. That's
> true
> > for indexing analyzers, and that's als

[hibernate-dev] [SEARCH] Remove support for (or deprecate) date/calendar resolution?

[Yoann Rodiere]

Hi,

That's a catchy subject, now I'm sure I got Guillaume's (angry) attention :)

Sanne wanted us to think about feature removal... Here's a proposal.

The feature I'd like to deprecate/remove: automatic truncation of
date/calendars to a given resolution. It's used like that:

@Field
@CalendarBridge(resolution = Resolution.DAY)
private Calendar dateSent;

I've been working on date-related tests for the past few hours (well,
months, too), and I'm becoming more and more convinced that this resolution
thing is the wrong solution to an admittedly common issue. The other (in my
opinion right) solution being to use range queries.

When we truncate a date to a given resolution, we must use a particular
timezone, obviously. It makes no sense to truncate to the day when we don't
choose a particular timezone.
Then the truncated date will match only if we search for dates whose
truncation is identical in this timezone.

And guess what? In the current implementation, we use... GMT. Always. See
how org.apache.lucene.document.DateTools.round(long, Resolution) works,
getting the calendar used for truncation from TL_CAL, which uses the GMT
timezone.

What it means is that the truncation currently produces rather unexpected
results as soon as applications use a timezone different from GMT.

So it's likely to be considered as broken:

   - for multi-timezone applications
   - for single-timezone applications using a different timezone than GMT

For instance, let's index 2016-01-01T00:00:00+01:00 and query
2016-01-01T12:00:00+01:00 with a DAY resolution:

   - We'll index 2015-12-31 (2016-01-01T00:00:00+01:00 is
   2015-12-31T23:00:00+00:00, which once truncated is 2015-12-31+00:00)
   - We'll query 2016-01-01 (2016-01-01T12:00:00+01:00 is
   2016-01-01T11:00:00+00:00, which once truncated is 2016-01-01+00:00)

That won't match, but from the point of view of a single-timezone user it
should have.

Of course I'm exaggerating a bit, and the issue probably hasn't been
noticed by many, because:

   - there is no problem with the MINUTES, SECONDS and MILISECONDS
   resolutions, which are not affected by timezones
   - there is no problem with the HOUR resolution in most timezones (there
   is a problem, however, when the timezone is something like -11:30)
   - the problem is less likely to be detected when the user timezone is
   close to GMT, because then only date/times close to midnight (i.e. outside
   business hours) will be affected.

But my point is: the current solution produces counter-intuitive, sometimes
even useless results.

It was useful when dates were indexed as strings, but now that we (mostly)
index them as integers, this does not seem relevant. Even the DateTools
javadoc hints that DateTools (including "round") are not relevant for
numeric dates:

 Another approach is {@link NumericUtils}, which provides
>  a sortable binary representation (prefix encoded) of numeric values, which
>  date/time are.
>  For indexing a {@link Date} or {@link Calendar}, just get the unix
> timestamp as
>  long using {@link Date#getTime} or {@link
> Calendar#getTimeInMillis} and
>  index this as a numeric value with {@link LongField}
>  and use {@link NumericRangeQuery} to query it.



What I'd like to propose is to deprecate or remove date/calendar
resolution, or limit it to STRING encoding, and instead encourage users to
query their dates with range queries whenever they don't want exact matches.

Of course we could also implement a way for users to customize the timezone
to be used when truncating. But range queries have other advantages:

   - they fit the multi-timezone use case
   - they allow to query the same field with multiple resolutions

At the very least, I'd like us to agree that in the future, we will only
implement automatic truncation with date/time types where the timezone is
either irrelevant or included (for instance ZonedDateTime or LocalDate or
LocalTime, but *not* Instant).

Relevant ticket: https://hibernate.atlassian.net/browse/HSEARCH-2378.

What do you think?

Yoann Rodière 
Hibernate NoORM Team
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [SEARCH] Remove support for (or deprecate) date/calendar resolution?

[Yoann Rodiere]

> We used it a lot at OW and I'm sure it's pretty widespread out there (and
even when we didn't use HS but Solr, we needed an equivalent feature).
Using range queries is a solution but it's a bit cumbersome for such a
common requirement.

Please note that Hibernate Search queries are now built using a wrapper in
OWSI-Core
<https://github.com/openwide-java/owsi-core-parent/blob/bd6ab1ec1d54c22ed3b2f8f94362b43223b01342/owsi-core/owsi-core-components/owsi-core-component-jpa-more/src/main/java/fr/openwide/core/jpa/more/business/search/query/HibernateSearchLuceneQueryFactoryImpl.java>
in
most recent applications, and it could easily be adapted to add a Date
match method (using method overloading). In fact, if I remember correctly I
had to do exactly that for one application.

One thing to note about the OW use case, too: I've never seen anything
other than a Date being used in business models of single-timezone
applications at Open Wide. See below why it's relevant.

> I think this new behavior would fix most of the issues you mention.

An easier implementation would be what you did with Elasticsearch using the
clone() method. But anyway, this would only fix the issue for Calendar. For
Date, we basically only have a GMT timestamp with no timezone data nor
field-based data, so there's really nothing we can do.
If we want to fix the default behavior for dates, the only solution I can
see is to use the default JVM timezone instead of GMT, maybe...

> And if you really need the behavior when dates in one time zone might be
a different date in a different time zone, then you definitely wouldn't use
the resolution option and stick to the full date with range queries.

All dates in one time zone may be a different date in a different time
zone... In fact, I'm pretty sure all dates in one time zone *are* a
different date in one different time zone. I see what you mean, but I just
wanted to point out how difficult it will be to explain properly in the
documentation. I don't know about you, but I really don't want to explain
in the docs that "this feature should only be used with java.util.Date if
your timezone is close to GMT", and I want even less to explain why...

Anyway, you do understand we're offering a feature that won't work properly
in most time zones, and will simply not work most of the time in time zones
such as, for instance, the one for the US west coast (UTC-8)? (in that
specific case it won't work after 4 PM).

Could we agree the current behavior should change, not only for
java.util.Calendar but also for java.util.Date?
If we do, we'll probably have to wait for 6.0, because users will have to
perform a full reindex after upgrading to a version of Hibernate Search
with the fix, even if they previously weren't affected by the bug.

Also:

> At the very least, I'd like us to agree that in the future, we will only
implement automatic truncation with date/time types where the timezone is
either irrelevant or included (for instance ZonedDateTime or LocalDate or
LocalTime, but *not* Instant).

Do you agree with the statement above?


> I would pay to see your face while reading this email :).

Yeah, well, not much surprise here :)

Yoann Rodière 
Hibernate NoORM Team

On 9 January 2017 at 12:53, Guillaume Smet  wrote:

> Hi,
>
> On Thu, Jan 5, 2017 at 5:20 PM, Yoann Rodiere  wrote:
>
>> That's a catchy subject, now I'm sure I got Guillaume's (angry) attention
>> :)
>>
>> Sanne wanted us to think about feature removal... Here's a proposal.
>>
>> The feature I'd like to deprecate/remove: automatic truncation of
>> date/calendars to a given resolution. It's used like that:
>>
>
> Yeah, as you can imagine, I'm pretty reluctant to the idea of removing
> this feature. We used it a lot at OW and I'm sure it's pretty widespread
> out there (and even when we didn't use HS but Solr, we needed an equivalent
> feature). Using range queries is a solution but it's a bit cumbersome for
> such a common requirement.
>
> I agree the current behavior might lead to unexpected results. To be
> honest, I think we should simply ignore the timezone when truncating. I
> mean, when I want to index at a day resolution, I want to index the user
> facing day, not the one in the server time zone or in GMT.
>
> So for instance, for 2016-01-01T00:00:00+01:00, I would index 2016-01-01,
> not 2015-12-31.
>
> So, as long as the resolution is less precise than day included, what I
> would do is in fact remove our call to DateTools.round and have something
> like:
> - create a GMT GregorianCalendar
> - don't set the calendar value using the time in millis but with the
> original fields from the calendar passed in parameter (or 0/1 depending on
> 

[hibernate-dev] Hibernate Search 5.5.6.Final released

[Yoann Rodiere]

Hello everyone,

We just released Hibernate Search 5.5.6.Final with the latest bugfixes.

For more information, please see our blog:

http://in.relation.to/2017/01/09/hibernate-search-5-5-6-Final/

Yoann Rodière 
Hibernate NoORM Team
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [OGM] Keeping the order of the collection of elements in MongoDB

[Yoann Rodiere]

>
> I think it's a reasonable expectation, as long as we're talking
> specifically about mapping a *List* and not just a generic Collection.
>

Ah, this topic again :) I know I'll be all lone, but I'll try anyway!

If we do it for List, and unless there are technical issues that prevent us
from doing so, I would be in favor of doing it for any kind of collection.

In Collections, the fact that iteration order is deterministic is mostly up
to the implementation, which is different from saying it's not
deterministic. From the javadoc for Collection#iterator():

There are no guarantees concerning the order in which the elements are
> returned
> (unless this collection is an instance of some class that provides a
> guarantee).


Deterministic, and even predictable order is not exclusive to List, either:
for instance, LinkedHashSet is not a List, it has a specific iteration
order, but there is nothing in its implemented interfaces (Collection, Set)
that defines this order.

My point is, we can't rely on the implemented interface to decide whether
the iteration order is important or not, so we may as well decide it is
always important. Unless there are annoying technical challenges, of course.


Yoann Rodière 
Hibernate NoORM Team

On 13 January 2017 at 13:48, Sanne Grinovero  wrote:

> I think it's a reasonable expectation, as long as we're talking
> specifically about mapping a *List* and not just a generic Collection.
>
> On 13 January 2017 at 12:18, Davide D'Alto  wrote:
> > Hi,
> > it seems that when using Collection of elements in MongoDB, users
> > expect to have the elements in the same order as in the db. You can
> > see the question on the forum here:
> > https://forum.hibernate.org/viewtopic.php?f=31&t=1043903&;
> p=2491218#p2491218
> >
> > I also found this StackOverflow question:
> > http://stackoverflow.com/questions/9013916/do-arrays-
> stored-in-mongodb-keep-their-order
> >
> > What do you think? Is it something that we should support?
> >
> > Cheers,
> > Davide
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [OGM] Keeping the order of the collection of elements in MongoDB

[Yoann Rodiere]

er,
> but you're rather more interested in accepting a wide range of
> implementations, some of which might ignore the ordering requirement.
> By doing so, you're explicitly telling both ORM and your other code
> interacting with the model that ignoring the order is acceptable.
>
> BTW I suspect mapping things as a generic Collection is a very unusual
> (or lazy) choice; I don't remember ever using it as it's quite
> ambiguous, and there's no way any specification diagram will lead you
> to recommend using a Collection (other than cleanly and explicitly
> wanting to express you don't care about ordering, nor other properties
> like uniqueness...)
>
> Thanks,
> Sanne
>
>
> On 13 January 2017 at 13:29, Yoann Rodiere  wrote:
> >> I think it's a reasonable expectation, as long as we're talking
> >> specifically about mapping a *List* and not just a generic Collection.
> >
> >
> > Ah, this topic again :) I know I'll be all lone, but I'll try anyway!
> >
> > If we do it for List, and unless there are technical issues that prevent
> us
> > from doing so, I would be in favor of doing it for any kind of
> collection.
> >
> > In Collections, the fact that iteration order is deterministic is mostly
> up
> > to the implementation, which is different from saying it's not
> > deterministic. From the javadoc for Collection#iterator():
> >
> >> There are no guarantees concerning the order in which the elements are
> >> returned
> >> (unless this collection is an instance of some class that provides a
> >> guarantee).
> >
> >
> > Deterministic, and even predictable order is not exclusive to List,
> either:
> > for instance, LinkedHashSet is not a List, it has a specific iteration
> > order, but there is nothing in its implemented interfaces (Collection,
> Set)
> > that defines this order.
> >
> > My point is, we can't rely on the implemented interface to decide whether
> > the iteration order is important or not, so we may as well decide it is
> > always important. Unless there are annoying technical challenges, of
> course.
> >
> > Yoann Rodière 
> > Software Engineer
> > Red Hat / Hibernate NoORM Team
> >
> > On 13 January 2017 at 13:48, Sanne Grinovero 
> wrote:
> >>
> >> I think it's a reasonable expectation, as long as we're talking
> >> specifically about mapping a *List* and not just a generic Collection.
> >>
> >> On 13 January 2017 at 12:18, Davide D'Alto 
> wrote:
> >> > Hi,
> >> > it seems that when using Collection of elements in MongoDB, users
> >> > expect to have the elements in the same order as in the db. You can
> >> > see the question on the forum here:
> >> >
> >> > https://forum.hibernate.org/viewtopic.php?f=31&t=1043903&;
> p=2491218#p2491218
> >> >
> >> > I also found this StackOverflow question:
> >> >
> >> > http://stackoverflow.com/questions/9013916/do-arrays-
> stored-in-mongodb-keep-their-order
> >> >
> >> > What do you think? Is it something that we should support?
> >> >
> >> > Cheers,
> >> > Davide
> >> > ___
> >> > hibernate-dev mailing list
> >> > hibernate-dev@lists.jboss.org
> >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >> ___
> >> hibernate-dev mailing list
> >> hibernate-dev@lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> >
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [OGM] Keeping the order of the collection of elements in MongoDB

[Yoann Rodiere]

>
> I'm a bit lost here. If you don't want to expose an "unnecessary
> promise" like ordering, why would you need OGM to maintain ordering?


As explained below:

> You could add documentation on a getter stating what the expected ordering
> is (and, frankly, it may be relevant even with a List: how would you
> translate "the invoices are ordered by issuing date" in terms of a Java
> interface?). But what you cannot (or at least, shouldn't) do is
> contradicting the interfaces you expose ("yeah, I'm exposing a List because
> elements are ordered explicitly since we only ever add one at the end, but
> please be nice and don't try random access, it's a very long linked list").
>

In my example, ordering *was* necessary (since we state that invoices are
ordered by issuing date). What wasn't necessary was all the other contracts
exposed by List ("you can do random access", "you can manage ordering
explicitly", etc.), which is why someone may not want to use a List.
In the real world I guess that people who find such thing annoying will
have several layers of abstraction on top of their entities anyway, but
still.

ah, maybe I understand now. If you're proposing we do a similar thing
> for other specific collection types then sure we can discuss that. I
> had the impression you wanted to store ordering for properties
> literally using the *Collection* signature.


Well, I *also* wanted to store ordering for those, as long as "storing the
ordering" only means putting the elements in the correct order in the
resulting document.
But I'll be happy if we do it only for the sake of custom collection types,
since I suspect it means we will also do it for the default types :)

By the way, a property can have a Collection signature and *also* have a
custom type, it's not mutually exclusive. Actually, there's even an example
in Hibernate ORM tests (and documentation, apparently):

//tag::collections-custom-collection-mapping-example[]
@Entity(name = "Person")
public static class Person {

@Id
private Long id;

@OneToMany(cascade = CascadeType.ALL)
@CollectionType( type = "org.hibernate.userguide.
collections.type.QueueType")
private Collection phones = new LinkedList<>();

//Getters and setters are omitted for brevity

//end::collections-custom-collection-mapping-example[]

public Person() {
}

public Person(Long id) {
this.id = id;
}

public Queue getPhones() {
return (Queue) phones;
}
//tag::collections-custom-collection-mapping-example[]
}

Keeping such ordering might come at a non-trivial cost; sometimes just
> computation wise, sometimes on query complexity and/or space when the
> order column needs to be stored. It just happens to be cheap and -
> apparently - "natural" on MongoDB.


Sure, we should only do it where it's possible efficiently.

BTW I'm not even 100% convinced about my previous suggestion about
> supporting this, as maybe it would set a bad precedent?
> The risk is that after developing on OGM/MongoDB you start expecting
> this to work fine on other systems, so from this perspective our API
> would not have a clear contract on the expectations one should have.

True... On the other hand, not implementing something that *is* efficient
for MongoDB would be annoying for users, too. And more rightly so.
Also, it would require a fair bit of bad faith from users to blame us for
not implementing an unspecified behavior... even if other dialects do
implement it.

If we really want to have a clear contract, it means we have to explicitly
state somewhere that ordering is undefined unless one is using @OrderColumn
/ @OrderBy. If we really want to do this, we may as well add "unless you're
using a document database" or something like this?

Yoann Rodière 
Hibernate NoORM Team

On 13 January 2017 at 16:54, Sanne Grinovero  wrote:

> On 13 January 2017 at 15:30, Yoann Rodiere  wrote:
> > Hi Sanne,
> >
> >>
> >> while you might be using a specific implementation when persisting
> >> your new entities, when you're loading the object back from the
> >> database how is Hibernate supposed to know
> >>  A) which implementation you want it to use
> >
> > Ok, that's true for most collection interfaces, but I'm not sure I
> > understand why what Hibernate can guess is relevant here. Users are free
> to
> > use custom collection types, at least in ORM. Is it not the case with
> OGM?
> > Will it never be possible?
>
> Sure, OGM should (eventually?) be able to do the same as ORM.
>
> But in this case we're not talking about the case in which you use a
> custom collection; my question is if you map a "Collection" with
> nothing else than a - for 

Re: [hibernate-dev] [HV/HSEARCH] Free form

[Yoann Rodiere]

Hi,

Did the same this week-end, and adapted your work to match the bigger
picture of what we discussed on Friday.
Basically the "StructureTraverser" is now called "ValueProcessor", because
it's not responsible for exposing the internals of a structure anymore, but
only to process a structure according to previously defined metadata,
passing the output to the "DocumentContext". I think it's the second option
you suggested. It makes sense in my opinion, since metadata will be defined
differently for different source types (POJO, JSON, ...).
This design allows in particular what Sanne suggested: when
bootstrapping, we can build some kind of "walker" (a composition of
"ValueProcessors") from the metadata, and avoid metadata lookup at runtime.

The snippet is there: https://gist.github.com/yrodiere/
9ff8fe8a8c7f59c1a051b36db20fbd4d

I'm sure it'll have to be refined to address additional constraints, but in
its current state it seems to address all of our requirements.


Yoann Rodière 
Hibernate NoORM Team

On 27 January 2017 at 18:23, Emmanuel Bernard 
wrote:

> I took the flight home to play with free form and specifically how we
> would retrieve data from the free form structure.
> By free-form I mean non POJO but they will have schema (not expressed
> here).
>
> https://github.com/emmanuelbernard/hibernate-search/commit/
> 0bd3fbab137bdad81bfa5b9934063792a050f537
>
> And in particular
> https://github.com/emmanuelbernard/hibernate-
> search/blob/freeform/freeform/src/main/java/org/hibernate/
> freeform/StructureTraverser.java
> https://github.com/emmanuelbernard/hibernate-
> search/blob/freeform/freeform/src/main/java/org/hibernate/
> freeform/pojo/impl/PojoStructureTraverser.java
>
> It probably does not compile, I could not make the build work.
>
> I figured it was important to dump this raw thinking because it will
> influence and will be influenced by the redesign of the DocumentBuilder of
> Hibernate Search.
>
> There are several options for traversing a free form structure
> - expose  the traversing API as a holder to  navigate all properties per
> structure and sub structure. This is what the prototype shows. Caching
> needs to be accessed via a hashmap get or other lookup. Metadata and the
> traversing structure will be navigated in parallel
> - expose a structure that is specialized to a single property or container
> unwrapping aspect. The structures will be spread across and embedded in the
> Metadata
>
>
> Another angle:
> - create a traversable object per payload to carry it (sharing metadata
> info per type)
> - have a stateless traversable object that is provided the payload for
> each access
>
> The former seems better as it does not create a traversable object per
> object navigated.
> The latter is better for payloads that need parsing or are better at
> sequential access since state could be cached.
>
> We need to discuss that and know where DocumentBuilder is going to
> properly design this API.
>
> Emmanuel
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Hibernate Commons project

[Yoann Rodiere]

Everything you said seems to make sense to me, so +1.
We can see later whether we agree on the other common projects we could add
(checkstyle rules, test utils, ...), but I think there won't be many
arguments *against* them as long as there is no transitive dependency to
these projects for end users. It's mostly about how we work internally,
after all.

About the specifics:

== The groupId

To me it seems to make perfect sense to move hibernate-commons-annotations
to the same repo, but I can understand it'll cause some trouble to
developers. At the very least we could just rename
org.hibernate:hibernate-commons-annotations to
org.hibernate.commons:hibernate-commons-annotations, so that we'll be
consistent with the other 6.x groupId renamings. As for moving code between
repos, we can always see about that later: it won't impact end users.

== The license

On the license side, I think we can only license our common projects under
Apache License 2, because one cannot include LGPL work within an ASL2 work.
So using LGPL would prevent us from using the projects in HV... probably.
Source: http://www.apache.org/legal/resolved.html#category-x
> The LGPL is ineligible primarily due to the restrictions it places on
larger works, violating the third license criterion.


Yoann Rodière 
Hibernate NoORM Team

On 30 January 2017 at 11:23, Guillaume Smet 
wrote:

> Hi,
>
> So, as discussed at the F2F, I set up an hibernate-commons project.
>
> Currently, it's here https://github.com/gsmet/hibernate-commons, waiting
> for everyone to agree on the name, the license, the purpose and so on.
>
> We would like to make quick progress on it as it's blocking for the
> migration of Search and OGM to the new AsciiDoctor output (we are still
> using Docbook as the final output for these projects). It would be nice if
> we could move them to this output for Search 5.7 and OGM 5.1 which are
> planned for the coming weeks.
>
> Basically the idea behind this repo is to centralize things useful to all
> (or several) Hibernate projects:
> - an AsciiDoctor theme
> - testing utilities we would like to share for all the Hibernate projects
> - (still to be decided as not that obvious) utilities we would like to
> share for the NoORM projects
>
> Things that should be discussed:
>
> == The groupId
>
> I used hibernate-commons as it seemed like an obvious groupId. The fact is
> that we already have hibernate-commons-annotations here.
>
> Thoughts?
>
> == The license
>
> Most of our projects are LGPL licensed except for HV which is Apache 2
> licensed. Which license should we choose?
>
> == The AsciiDoctor theme
>
> So the theme I put in is slightly different from the one from ORM:
> - the top banner is white instead of black. The black banner was a bit too
> aggressive to my taste;
> - I was very light on customizing the HTML output as I would really like us
> to not spend time on maintaining it. So it's basically the default output
> whereas ORM has customized the color of the titles of the links and several
> other things. I think the default output is really nice and we can keep it
> as is;
> - I customized the PDF output a bit more as there were problems with the
> default output. I think it's pretty good now.
>
> Here is the current output for Search:
> - HTML: http://docs.jboss.org/hibernate/beta/html_single/
> - PDF:
> http://docs.jboss.org/hibernate/beta/pdf/hibernate_search_reference.pdf
>
> -> note that if you want to use a specific theme for specific purposes, it
> would still be possible. It's a base you can configure with your own CSS
> and such.
>
> Thoughts?
>
> --
> Guillaume
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] NoORM - New groupId and relocation artifacts

[Yoann Rodiere]

One benefit we always get by being consistent is that it's easier for a
newcomer to switch from project to project... If it doesn't require more
work, we may as well be consistent.

Anyway, thanks Guillaume, I added this piece of information to the HSearch
ticket: https://hibernate.atlassian.net/browse/HSEARCH-2557

Yoann Rodière 
Hibernate NoORM Team

On 30 January 2017 at 13:01, Sanne Grinovero  wrote:

> Nothing major, but still this got me wondering:
>  - why the parent pom "hibernate-validator-relocation" ?
>  - why the profile switch? do you plan to omit these artifacts for -
> say - nightly builds and local testing of other projects depending on
> it?
>  - what's the benefit you're hoping to achieve by being consistent
> with this approach?
>
> Thanks,
> Sanne
>
>
> On 30 January 2017 at 09:55, Guillaume Smet 
> wrote:
> > Hi,
> >
> > So, with Gunnar, we did the work to rename the groupId and relocate the
> > artifacts of Validator.
> >
> > It would be nice if we could be consistent on the way we do it.
> >
> > So what we did:
> > - we created a relocation/ directory/parent artifact containing all the
> > relocation artifacts
> > - we only enable the build of the relocation artifacts if the relocation
> > profile is enabled (the release scripts are already updated to take this
> > new profile into account)
> >
> > See these commits for the details:
> > -
> > https://github.com/hibernate/hibernate-validator/commit/
> 744b4c525c527e510648da8fed6c7e0fce8dd95c
> > -
> > https://github.com/hibernate/hibernate-noorm-release-scripts/commit/
> 0fd44ecb06fd8269d8498affdd8e9c2a0c5836d4
> >
> > If you have any question, feel free to ask.
> >
> > HTH
> >
> > --
> > Guillaume
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Hibernate Commons project

[Yoann Rodiere]

On 30 January 2017 at 13:58, Guillaume Smet 
 wrote:

> Note that the current version of hibernate-commons-annotations is
> org.hibernate.common (without the s at the end, not org.hibernate as Yoann
> stated it).
>
You're right. Wouldn't the simplest solution be to use the same groupId
(without a "s") in our new repo?



> Moving hibernate-commons-annotations is not such a good idea IMHO:
> - it's licensed under the LGPL so it would force us to use this license (or
> relicense it or having different licenses for the submodules but they are
> all bad ideas)
>

It sure seems complicated. But relicensing from LGPL to ASL2 may not be
such a big deal, since LGPL seems stricter than ASL2.
Couldn't we simply dual-license the whole repository under ASL2/LGPL? That
way, previous users wouldn't need to be aware of the change, and new users
could choose to comply with whichever suits them best.
Or does it require to release two packages for each submodule (one for each
license)?

Anyway... there are other reasons for not wanting to move the code to
another repo, so maybe we could just focus on having consistent group IDs
and let the code live in different places and have different maven parents.



> - we would release a new version of this module each time we want to
> upgrade the theme and I don't think it would be readable for consumers of
> this preexisting artifact.
>
> The latter point is what worries me about centralizing all the utils in the
> same repo with the same lifecycle.
>

We already got through this discussion, but let's sum it up:

   - With a common versioning, consuming projects will only have to take
   care to use the latest version available and use it for every common
   project they depend on.
   - With a common versioning, consuming projects will retain the ability
   to punctually use an older version for some subproject.

Sure, on the day we decide to break something, we'll have to bump the minor
or major for every "common" project, and it will give the false impression
that every such project has breaking changes. But we don't wan't to do that
often, and we'll probably won't have so many common projects anyway.

Having separate lifecycles/repos is probably cleaner, but it has its own
downsides:

   - Consuming poms will be less readable and less easily updated (one
   version per consumed common project).
   - Releasing the common projects will be more work.
   - Maintenance will be a bit harder (having multiple scattered repos to
   work on).
   - We'll run the risk of some common projects not being updated, in
   particular the version of their dependencies. Which could be avoided, or at
   least be less likely, if we centralize the dependency management in the
   parent pom of the common projects.

We can leave hibernate-common-annotations where it is, since it's
pre-existing and already critical in several of our projects, so its
maintenance is pretty much guaranteed.
But that kind of splitting seems dangerous for the new common projects,
because it makes it harder to maintain them, and there will be no full-time
maintainers. So we'd better not split these common projects any further,
and give these projects a chance to get regular maintenance...
Yoann Rodière 
Hibernate NoORM Team
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate Search 5.6.0.Final and 5.7.0.CR1 released

[Yoann Rodiere]

Hello,

We just released Hibernate Search 5.6.0.Final, the first stable release
featuring experimental support for Elasticsearch (2.x).

We also started the candidate release phase for Hibernate Search 5.7 by
releasing version 5.7.0.CR1, with support for ORM 5.2.7 and newer (but not
older, see the blog post).
This is the last step before 5.7 is released, so be sure to check it out so
you can share your thoughts with us before the release!

For more information, please see our blog:

http://in.relation.to/2017/01/30/hibernate-search-5-6-0-Final-and-5-7-0-CR1/

Cheers,

Yoann Rodière 
Hibernate NoORM Team
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [HV/HSEARCH] Free form

[Yoann Rodiere]

ifferent focus in our solutions.

   1. Emmanuel's solutions focuses on abstracting over the input data
   format (thanks to StructureTraverser), assuming the traversal algorithm
   will be re-implemented for each output type.
   2. My solution focuses on abstracting over the output data format
   (thanks to DocumentBuilder), assuming the traversal algorithm will be
   re-implemented for each input type using different ValueProcessors.
   3. Gunnar's solution seem to focus on abstracting over the output data
   format, reimplementing the traversal algorithm for each input type using a
   different TreeTraversalSequence.

Solution 1 and 2 are, in my opinion, compatible. We could have very generic
ValueProcessors that would make use of a StructureTraverser to extract data
and of a DocumentBuilder to inject it into a document. I'm not sure it is
necessary, because I expect metadata to be defined differently based on the
input type, and hence the traversal algorithms to be slightly different,
but I think we could do it.

About solution 3: TreeTraversalSequence seems to implement the traversal
algorithm, while TreeTraversalEventConsumer abstracts over the output
format and TreeTraversalEvent abstracts over the information being
transferred.
I think the general principles are more or less equivalent to solution 2.
The main difference are:

   - How the context around the data to transfer is propagated.
   In solution 2, we pass the context progressively by making call to the
   DocumentBuilder (documentBuilder.nest(...), documentBuilder.addField(...)).
   In solution 3, the context is explicitly modeled as a TreeTraversalEvent.
   - How metadata is looked up.
   In solution 2, the metadata is built in the objects implementing the
   traversal algorithm, so there is no look up to speak of. In solution 3,
   there is a metadata lookup for each node in the tree.

Maybe there's a matter of performance, but I don't know enough about this
to give a definitive answer. In the end it's probably more a matter of
taste.


Yoann Rodière 
Hibernate NoORM Team

On 7 February 2017 at 11:17, Gunnar Morling  wrote:

> Emmanuel,
>
> In your PoC, how would a complete tree-like structure be traversed?
> It's not clear to me, who is driving StructureTraverser, i.e. which
> component will call processSubstructureInContainer() et al. when
> traversing an entire tree.
>
> @Yoann, maybe you can add a usage example similar to Emmanuel's? You
> have a lot of framework code, but I'm not sure about how it'd be used.
>
> For Hibernate Search, the traversal pattern I implemented for the
> ScenicView PoC may be of interest. Its general idea is to represent a
> tree traversal as a sequence of events which a traverser
> implementation receives and can act on, e.g. to create a corresponding
> de-normalized structure, Lucene document etc. The retrieval of values
> and associated objects happens lazily as the traverser
> ("TreeTraversalEventConsumer" in my lingo) pulls events from the
> sequence, similar to what some XML parsers do.
>
> The main contract can be found at [1]. There are two event sequence
> implements, one based on Hibernate's meta-model [2] and one for
> java.util.Map [3]. An example event consumer implementation which
> creates MongoDB documents can be found at [4].
>
> As said I think it'd nicely fit for Hibernate Search, for HV I'm not
> so sure. The reason being that the order of traversal may very,
> depending on the defined validation groups and sequences. Sometimes we
> need to go "depth first". I've been contemplating to employ an
> event-like approach as described above for HV, but it may look
> different than the one used for HSEARCH.
>
> --Gunnar
>
> [1] https://github.com/gunnarmorling/scenicview-mvp/
> blob/master/core/src/main/java/org/hibernate/scenicview/spi/backend/model/
> TreeTraversalSequence.java.
> [2] https://github.com/gunnarmorling/scenicview-mvp/
> blob/master/core/src/main/java/org/hibernate/scenicview/internal/model/
> EntityStateBasedTreeTraversalSequence.java
> [3] https://github.com/gunnarmorling/scenicview-mvp/
> blob/master/core/src/test/java/org/hibernate/scenicview/test/traversal/
> MapTreeTraversalSequence.java
> [4] https://github.com/gunnarmorling/scenicview-mvp/
> blob/master/mongodb/src/main/java/org/hibernate/scenicview/
> mongodb/internal/MongoDbDenormalizationBackend.java#L91..L128
>
>
>
> 2017-02-06 16:49 GMT+01:00 Emmanuel Bernard :
> > Your prototype is very Hibernate Search tainted. I wonder how or whether
> we want it reusable across Hibernate Validator, Search and possibly more.
> >
> > Have you captured somewhere the discussion about the new document
> builder so I could get a better grip of what’s at bay?
> > Would this

[hibernate-dev] [SEARCH] Integration of Mincong's work on adding JSR-352 support

[Yoann Rodiere]

Hello,

Following our recent (and successful) efforts to fix blocking issues on
https://github.com/mincong-h/gsoc-hsearch/, I recently added a branch on my
repo which contains the Hibernate Search codebase, with the addition of a
JSR-352 submodule. You can find the branch at [1]. The build is working
just fine ([2]).

I tried to preserve as much metadata as possible when building this branch,
without keeping a long list of commits that would probably do more harm
than good. Basically I squashed commits and put the git log of the squashed
commits in the commit's comment. I tried to preserve authorship and
approximate dates, so git blame will still be useful.

If this branch seems acceptable to everyone, we can start working on
further polishing the JSR-352 integration, and eventually merge it. Below
are the next few steps to discuss.

# What's left to do

The full list of remaining issues can be found on the original repo [3]. I
marked as "Blocker" those issues that seem unacceptable in a release.

To sum up:

   - we have some APIs that will need further refining (just a few);
   - we basically don't have any documentation (there is a start, but it's
   already obsolete);
   - we lack some tests, most notably integration tests with other
   implementations than JBeret;
   - composite IDs are not supported correctly;
   - there are performance issues (or at least there were last time we
   checked);
   - failure recovery doesn't seem to be implemented correctly (uses
   AddLuceneWork instead of UpdateLuceneWork for the failing partition);
   - there are still questions about how transaction timeouts should be
   handled.

# Organization

I'd like to avoid merging the branch to master as long as the module isn't
ready. Here's why:

   1. The module isn't ready for prime-time yet (see above)
   2. The module is only loosely tied to Hibernate Search, in a few very
   specific portions of the code, so rebasing it shouldn't be hell. And it'll
   probably be me doing it anyway ;)

So think we should leave the code where it is now (a branch on my repo, see
[1]) and manage pull requests there.

About CI, Travis is working just fine for me, and since we're working on an
additional module the changes we make shouldn't have any impact on the
core. So I don't think setting up a job on ci.hibernate.org is required yet.

Regarding the tickets, I would create issues in our JIRA based on the
existing GitHub issues in the original repo. Probably make them sub-tasks
of HSEARCH-2594 [4]. I'll work on this later this week if nobody is against
it.

As to the planning, I'd say our problem isn't so much the amount of work
(there shouldn't be much more than 2 or 3 man-weeks remaning) than the
amount of time we can put into it.
Mincong isn't studying anymore and has a full-time job; however, he
generously proposed to work on this during his week-ends. But it obviously
wouldn't be reasonable to expect him to work on this every week-end, all
week-end long.
As for Sanne and myself, we'll be working on ES5 integration + Search 5.8 +
Search 6, so we also have a lot to do. I think I'll book some time slots (1
day a week maybe) to work on JSR-352 until we consider the module ready.

Any opinions on all this?

[1] https://github.com/yrodiere/hibernate-search/tree/jsr352
[2] https://travis-ci.org/yrodiere/hibernate-search/builds/203727344
[3] https://github.com/mincong-h/gsoc-hsearch/issues
[4] https://hibernate.atlassian.net/browse/HSEARCH-2594


Yoann Rodière 
Hibernate NoORM Team
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate Search 5.7.0.Final and 5.6.1.Final released

[Yoann Rodiere]

Hello everyone,

We just released Hibernate Search 5.7.0.Final, compatible with Hibernate
ORM 5.2.8.

As 5.7 is not compatible with Hibernate ORM 5.0/5.1 anymore, we also
released a bugfix version for 5.6 with several backports: Hibernate Search
5.6.1.Final.

Be sure to check out our blog for more information about those two releases:

http://in.relation.to/2017/02/22/hibernate-search-5-7-0-Final/

Have a nice day,

Yoann Rodière 
Hibernate NoORM Team
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] JIRA usage for OGM

[Yoann Rodiere]

Isn't marking those as "New feature" enough? Or, if necessary, tagging them?
I obviously can't tell how others use JIRA, but personally I don't dive
into old tickets every day. Most of the time I only check the new
(incoming) tickets and those assigned to the next release. So, those extra
tickets are only a problem when setting the goals for the next release, and
we could easily tag them so as to exclude them from our searches.

The actual question may be: when those tickets are solved, will they be
released synchronously with OGM releases? I.e., will the contrib repository
be released at the same time as OGM? If not, then yes, I'd say we'd better
move these tickets to another JIRA project.


Yoann Rodière 
Hibernate NoORM Team

On 16 March 2017 at 14:14, Sanne Grinovero  wrote:

> There are more than 300 open issues, which is fine but rather than
> being these well-defined issues most sound like wishful thinking of
> someone having a (possibly cool) idea but not really executing on it.
>
> Since JIRA is an issue tracker and not really a planning tool / note
> taking app I wish we could limit this practice of having issues like
> "explore integration with.." ?
>
> More specifically, could we move "out of the way" all issues related
> to Databases which we're moving into the "contrib" repository?
> I think it would be nice to have these in a different JIRA project.
>
> Thanks,
> Sanne
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] [SEARCH] 6.0: what if we flipped our metadata definition upside down?

[Yoann Rodiere]

Hello,

Currently, the medata definition mechanisms in Search work this way:

   - the primary way to define metadata is using annotations
   - the secondary way to define metadata is programmatic, *but it only
   instantiates annotations,* simulating annotated entities
   - classes needing to access those "low-level" metadata
   (AnnotationMetadataProvider in particular) only manipulate annotations

I'm wondering if we should change that, flipping the metadata definition
upside-down: the programmatic definition would be the main one, with a
clean, annotation-free low-level metadata model, and annotations would
merely be translated to this low-level metadata using a walker and the
programmatic API.

My first argument is that creating "simulated" annotations is rather odd,
but I'll grant you it's hardly receivable.
But I can see other, more objective reasons:

   - We periodically notice missing methods in the programmatic API ([1],
   [2], [3], [4]), because we thought "annotations first" and forgot about the
   programmatic API. If annotation processing was to rely on programmatic
   mapping, this "annotations first" thinking would not be a problem anymore,
   but rather a good thing: we would have to implement both the programmatic
   API and the annotations in order to make it work.
   - If we want to support programmatic mapping for "free-form" (i.e.
   non-POJO) entities, we will need to be more generic than what annotations
   allow at some point. We already spotted the problem of using "Class" to
   denote entity types, but there may be more. For instance denoting property
   identifiers, or property types, ... It just doesn't feel future-proof to
   rely on an intrinsically Java way of modeling metadata (the annotations)
   and try to model non-Java things with it...

What do you think? Are there any objections to making the programmatic API
the primary way to define metadata? Note that I'm not talking about making
users use it in priority (it won't change anything for them), just about
making it more central in our architecture.


|1]
http://stackoverflow.com/questions/43006746/hibernate-search-5-2-programmatic-configuration-of-facet-field
[2] https://hibernate.atlassian.net/browse/HSEARCH-1764
[3] https://hibernate.atlassian.net/browse/HSEARCH-2199
[4] https://hibernate.atlassian.net/browse/HSEARCH-1079

Yoann Rodière 
Hibernate NoORM Team
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [SEARCH] 6.0: what if we flipped our metadata definition upside down?

[Yoann Rodiere]

st we would have improved
the metadata provider, I guess.

We don't have to do this now, mind you, but I expect it to be very clearly
necessary when we'll introduce free-form support. Maybe we could just agree
that ideally, that's what we should do? Then we'll see how much the
metadata provider has changed when we'll implement free-form support, and
decide whether one more change is more risky or not.


Yoann Rodière 
Hibernate NoORM Team

On 27 March 2017 at 12:39, Sanne Grinovero  wrote:

> I don't mean this to be a strict "No", but I'm not convinced for now
> on the benefits such an exercise in refactoring brings..
>
> In a nutshell the goal is reading from {Annotations, ProgrammaticAPI}
> -> Actual applied Metadata.
>
> Independently from which one we read from first, won't there always be
> a risk of forgetting the other input processing blocks?
>
> Having one transformed into the other - like it is today - at least
> allows to make sure the interpretation of metadata is very consistent
> (when we don't forget about implementing support for an annotation).
> Keep in mind that we don't really create annotations: we just make
> sure to behave like they existed.
>
> You make a good point on free-form. We'll certainly need another
> "input -> actually applied Metadata", but in that case there's no need
> to be consistent with how annotations would be applied; in fact quite
> the opposite: I expect it to be beneficial to be able to do some
> things in a different way.
>
> So I DON'T expect this to evolve into:
> F({Annotations, ProgrammaticAPI, Free Form}) -> Actual applied
> Metadata.
> But rather two different operating modes:
>1#  F({Annotations, ProgrammaticAPI}) -> Actual applied Metadata.
>2#  Z({Free Form}) -> Actual applied Metadata & custom walkers.
>
> My point being that the two operations F() and Z() are intrinsically
> based on both different input APIs and requirements.
> While the purpose of the current Programmatic API, the fact that the
> working is very similar to annotations also has the side-effect of
> making the API intuitive for people who wish they could have added the
> annotation, but can't for some reason and have to fallback to this
> API: the picture they have in mind about their task is still similar
> to "add this annotation over there".
>
> I concur that the strategy to "simulate" annotations looks weird, but
> it's working fine, while such a significant refactoring poses various
> risks (both our time and likely regressions) for a benefit I'm not
> convinced of ;)
>
> Thanks,
> Sanne
>
> On 27 March 2017 at 09:06, Yoann Rodiere  wrote:
> > Hello,
> >
> > Currently, the medata definition mechanisms in Search work this way:
> >
> >- the primary way to define metadata is using annotations
> >- the secondary way to define metadata is programmatic, *but it only
> >instantiates annotations,* simulating annotated entities
> >- classes needing to access those "low-level" metadata
> >(AnnotationMetadataProvider in particular) only manipulate annotations
> >
> > I'm wondering if we should change that, flipping the metadata definition
> > upside-down: the programmatic definition would be the main one, with a
> > clean, annotation-free low-level metadata model, and annotations would
> > merely be translated to this low-level metadata using a walker and the
> > programmatic API.
> >
> > My first argument is that creating "simulated" annotations is rather odd,
> > but I'll grant you it's hardly receivable.
> > But I can see other, more objective reasons:
> >
> >- We periodically notice missing methods in the programmatic API ([1],
> >[2], [3], [4]), because we thought "annotations first" and forgot
> about the
> >programmatic API. If annotation processing was to rely on programmatic
> >mapping, this "annotations first" thinking would not be a problem
> anymore,
> >but rather a good thing: we would have to implement both the
> programmatic
> >API and the annotations in order to make it work.
> >- If we want to support programmatic mapping for "free-form" (i.e.
> >non-POJO) entities, we will need to be more generic than what
> annotations
> >allow at some point. We already spotted the problem of using
> "Class" to
> >denote entity types, but there may be more. For instance denoting
> property
> >identifiers, or property types, ... It just doesn't feel future-proof

Re: [hibernate-dev] Question about current flush ordering

[Yoann Rodiere]

On 28 March 2017 at 10:03, Vlad Mihalcea  wrote:

> There musts be a reason for choosing this ordering, but I can't figure out
> why the EntityDeleteAction was chosen to be executed last.
>

Isn't it simply to avoid foreign key constraints to explode? When you
update a reference to a foreign key *and* delete the previous target of
this reference in the same transaction, you want to execute the update
first and the delete last.

I can't imagine why orphan removals are executed first, though.

Yoann Rodière 
Hibernate NoORM Team
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [OGM] Hibernat OGM contrib repository

[Yoann Rodiere]

Hi,

I've moved the contributed dialect for OGM in this repository:
> https://github.com/DavideD/hibernate-ogm-contrib


Great, thanks :)

Which group id should we use? At the moment it is still
> org.hibernate.ogm but Iw odul opt for org.hibernate.ogm.contrib
>

+1 for org.hibernate.ogm.contrib. I would say let's use a different group
ID when the release cycles are different. Which is the case here.

What about the license? Can I re-use the same in Hibernate OGM?

I would say you will *have* to use the same, or a compatible one, unless
you want to ask permission to every single past contributor (which I think
is required to re-license a codebase)...


Yoann Rodière 
Hibernate NoORM Team

On 28 March 2017 at 12:28, Davide D'Alto  wrote:

> Hi all,
> I've moved the contributed dialect for OGM in this repository:
> https://github.com/DavideD/hibernate-ogm-contrib
>
> I have a couple of quesitons before moving it in an official repository:
>
> - Which group id should we use? At the moment it is still
> org.hibernate.ogm but Iw odul opt for org.hibernate.ogm.contrib
>
> - What about the license? Can I re-use the same in Hibernate OGM?
>
> I still need to update the README, this is the related PR for OGM:
> https://github.com/hibernate/hibernate-ogm/pull/850
>
> Thanks,
> Davide
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Hibernate Search: Adding more "hidden" fields to the index

[Yoann Rodiere]

I wonder, what's the benefit for HSEARCH-2616? Do you want to have that
field so that we can just use AddLuceneWorks everywhere, and run targeted
delete operations when we start a partition? If so, is it as a fallback
solution, if what I proposed cannot be implemented, or as a better
alternative? Note I don't have strong arguments against that solution, I'm
just trying to understand the "why".

On adding a hidden field, I wonder what this will mean for Elasticsearch;
if we start doing such things, we should clearly and explicitly state in
the documentation that targeting existing ES schemas without adapting them
to Hibernate Search is not supported.
On top of that, it may hurt users upgrading Hibernate Search: Lucene may
simply ignore queries against a field that doesn't exist in the index, but
I'm not sure Elasticsearch behaves that way when the field isn't even
defined in the mapping. So users may have to upgrade their schema just for
that. I know Elasticsearch integration is experimental anyway, but what I
mean is if we do that, it must be *before* Elasticsearch we drop the
"experimental" mention on Elasticsearch integration.


Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org

On 27 April 2017 at 15:59, Yoann Rodiere  wrote:

> I wonder, what's the benefit for HSEARCH-2616? Do you want to have that
> field so that we can just use AddLuceneWorks everywhere, and run targeted
> delete operations when we start a partition? If so, is it as a fallback
> solution, if what I proposed cannot be implemented, or as a better
> alternative? Note I don't have strong arguments against that solution, I'm
> just trying to understand the "why".
>
> On adding a hidden field, I wonder what this will mean for Elasticsearch;
> if we start doing such things, we should clearly and explicitly state in
> the documentation that targeting existing ES schemas without adapting them
> to Hibernate Search is not supported.
> On top of that, it may hurt users upgrading Hibernate Search: Lucene may
> simply ignore queries against a field that doesn't exist in the index, but
> I'm not sure Elasticsearch behaves that way when the field isn't even
> defined in the mapping. So users may have to upgrade their schema just for
> that. I know Elasticsearch integration is experimental anyway, but what I
> mean is if we do that, it must be *before* Elasticsearch we drop the
> "experimental" mention on Elasticsearch integration.
>
>
> Yoann Rodière
> Software Engineer, Hibernate NoORM Team
> Red Hat
> yrodi...@redhat.com
>
> On 27 April 2017 at 15:23, Sanne Grinovero  wrote:
>
>> To better implement recovery operations during MassIndexer
>> [HSEARCH-2616] - specifically in the context of the upcoming JBatch
>> based implementation - I'm considering the benefits of adding one more
>> field the the Lucene index for our internal purposes.
>>
>> This new field is only useful for Hibernate Search internals so we
>> shouldn't allow it to be targeted by queries, etc..
>>
>> There is a single precedent: we already encode the entity name, so
>> "hiding fields" is not a new problem that we have to deal with. It
>> might be a reason to polish the existing concept and improve the
>> encapsulation.
>>
>> Would anyone have a strong case against this?
>>
>> Thanks,
>> Sanne
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Hibernate Search: Adding more "hidden" fields to the index

[Yoann Rodiere]

> I had written the "why" on HSEARCH-2616, but to clarify here: [...]

Thanks. So the problem is that we may not be able to update the batch state
upon failure, in which case we would use the less-safe AddLuceneWork upon
restart.
If we had some way to store the information "this partition has started"
*before* we even write to the index, this wouldn't be a problem, but as you
might have guessed JSR-352 doesn't allow that.
So you're right, deleting everything before we even start working is our
best solution. And thus a hidden field will be necessary. I'll continue the
discussion on JIRA.

Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org

On 27 April 2017 at 18:19, Sanne Grinovero  wrote:

> On 27 April 2017 at 15:11, Yoann Rodiere  wrote:
> > I wonder, what's the benefit for HSEARCH-2616? Do you want to have that
> > field so that we can just use AddLuceneWorks everywhere, and run targeted
> > delete operations when we start a partition? If so, is it as a fallback
> > solution, if what I proposed cannot be implemented, or as a better
> > alternative? Note I don't have strong arguments against that solution,
> I'm
> > just trying to understand the "why".
>
> I had written the "why" on HSEARCH-2616, but to clarify here:
>
> I liked your idea of trying to figure out if the current block of work
> is being repeated, vs it being a re-try. However while I initially
> thought to add such a field as a fallback solution, I believe it's
> ultimately the more robust solution as otherwise you have to trust
> such state, which could be lost / wrong / corrupted independently for
> a number of reasons.
> Since the problem being solved is about resuming the process after a
> problem happened we can't make many safe assumptions about what kind
> of problem we're dealing with; for example if you run out of disk
> space you'll have an half-written index but no way to store such
> batch-state. Other problems might involve indexes being backed up /
> restored / replicated over other technologies (rsync, Infinispan, ..)
> so a mismatch between the index and other state is yet another problem
> which might need caution, logs and possibly tooling.
> Say an IO operation fails during an index write flush: some admin
> intervenes fixing hardware and then triggers resume of indexing.
> In such conditions I wouldn't trust some additional persistent state
> not even if it were cryptographically signed to be correct: corruption
> or signature mismatches could be detected but in this case there's the
> risk of it being trustful but out of date: with IO unavailable when
> this should have been written you're probably reading the previous
> version which had been written. Having an out of date batch state
> would likely have the opposite effect of what we need.
>
> On the other hand, inspecting what's in the index is coupled with the
> index state so while indexes could be corrupted, the progress tracking
> state and the index being one thing you're not easily fooled.
>
> Since I agree that having additional fields is not something everyone
> will like, as I suggested on HSEARCH-2616 we could offer the
> alternatives as fallback.
>
> >
> > On adding a hidden field, I wonder what this will mean for
> Elasticsearch; if
> > we start doing such things, we should clearly and explicitly state in the
> > documentation that targeting existing ES schemas without adapting them to
> > Hibernate Search is not supported.
> > On top of that, it may hurt users upgrading Hibernate Search: Lucene may
> > simply ignore queries against a field that doesn't exist in the index,
> but
> > I'm not sure Elasticsearch behaves that way when the field isn't even
> > defined in the mapping. So users may have to upgrade their schema just
> for
> > that. I know Elasticsearch integration is experimental anyway, but what I
> > mean is if we do that, it must be *before* Elasticsearch we drop the
> > "experimental" mention on Elasticsearch integration.
>
> Good point. Such proposals to change some internal field don't happen
> very often though.
>
> We strive to have a stable encoding, but since the index is not the
> database well documented changes might be worth it.
> Especially "private internal" fields should not be too hard to manage
> as we can deal with them explicitly in some lenient way, and if they
> don't contain end user state like in this case we don't even have to
> require an index rebuild.
>
> For people not wanting this they can have a slower mass indexer, or
> not support recovery.
>
> Thanks,
> Sann

Re: [hibernate-dev] Questions on HS + ES

[Yoann Rodiere]

Hi,

> * Can we have multiple indexes for the same entity, with different
> fields, geared towards different use cases?

No, it's not currently possible. Each entity is mapped to a single index.
But you can map each property of your entity to multiple index
"properties", so you can actually handle multiple use cases in a single
index.
We could probably think about adding the feature you describe, and it may
even not be very difficult (expect a few things that we'll have to do
anyway). But I fail to see the added value compared to having all those
fields in a single index. Performance-wise, I doubt it would change
anything, and on the user side the mapping would likely become harder to
understand (especially uses of @IndexedEmbedded).

> * How could we deal with authorization for seeing specific ES query
> results? I reckon that's something to mostly (solely?) handle on the
> ES side?

Hibernate Search itself does not provide any authorization features.
You can add security either:

   - on the ES side (with Shield) to define what the *application* is
   allowed to access (only the application scope makes sense here, since we
   use a single username for every request). This would involve updating index
   settings after they've been created or creating index templates before the
   indexes are created.
   - on the client side to define what a specific *user* is allowed to
   access, for example by annotating your services with Spring Security, which
   allows both pre-execution checks ("is this query parameter allowed") and
   post-execution checks ("is every result in the result set visible for the
   given user").

> * Are dynamic analyzers supported for the ES backend?

Nope, as mentioned in the docs [1]. They simply cannot be supported as is,
since with Elasticsearch, analyzers cannot be chosen when indexing, only
when creating the mapping.

> * And a wish for the docs: make clear which kind of changes towards
> mapped entities require a re-index run?

Any change that would result in already indexed entities to be indexed
differently: adding a new field based on pre-existing data, renaming a
field, changing its encoding (text to numeric for instance), changing how
it's analyzed (tokenizer, filter), making it stored while it previously
wasn't...
It's easier to state which changes do *not* require a re-index run,
actually:

   - new indexes/fields based on currently empty data, e.g. a new property
   in an entity that is currently empty for every entity, or a new index
   mapping for an entity that hasn't any database row yet.
   - feature reduction, e.g. making a previously stored field not stored,
   or removing a field. The data will stay in the index, we just won't use it
   nor update it anymore.

I created a ticket about this: HSEARCH-2715 [2].


Of course the limitations I just mentioned above are not carved in stone.
Hibernate Search evolves continuously, and if user feel like a specific
feature is missing, they can request it through JIRA.

[1]
https://docs.jboss.org/hibernate/stable/search/reference/en-US/html_single/#elasticsearch-limitations
[2] https://hibernate.atlassian.net/browse/HSEARCH-2715


Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org

On 9 May 2017 at 16:09, Gunnar Morling  wrote:

> Hi,
>
> I recently got some good questions on Hibernate Search + Elastisearch:
>
> * Can we have multiple indexes for the same entity, with different
> fields, geared towards different use cases?
> * How could we deal with authorization for seeing specific ES query
> results? I reckon that's something to mostly (solely?) handle on the
> ES side?
> * Are dynamic analyzers supported for the ES backend?
> * And a wish for the docs: make clear which kind of changes towards
> mapped entities require a re-index run?
>
> Any replies would be welcome.
>
> Thanks,
>
> --Gunnar
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] [SEARCH] Master nodes without class definitions

[Yoann Rodiere]

Hello,

In our roadmap for 5.8, we have this:

Removal of class definitions from master nodes
> The integration of a "master node" needs to be simplified, both in terms
> of user configuration and implementation. We plan to not need user classes
> (entities) on such a node, so that in future it could be a separate
> download which works out of the box with minimal configuration.


I guess what you are doing, Sanne, about replacing Class references with
an internal binding representation, is part of that, but there doesn't seem
to be any trace of those efforts in JIRA.

Is there a ticket about this? I don't think there is one with a 5.8 "Fix
version", but maybe somewhere else... ?

On a side note, there may be hidden complexity in having
mapping-independent master nodes: we can probably use a generic
representation of documents for document additions/updates, but with
 Elasticsearch, and probably very soon also with Lucene 7, we need to
initialize indexes with a schema. So at least one node needs both write
access to the indexes *and* knowledge of the mapping... Which
mapping-independent master nodes would prevent.

Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate Search 5.8.0.Beta2 released

[Yoann Rodiere]

Hello,

We just released Hibernate Search 5.8.0.Beta2, bringing us that much closer
to the final release.

You can find more information about 5.8 in general and the Beta2
specifically on our blog:

http://in.relation.to/2017/05/11/hibernate-search-5-8-0-Beta2/

Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] "rebranding" the Hibernate Search "ram" directory

[Yoann Rodiere]

Sanne, the confusions you pointed out were:

   - Thinking it's more efficient than other providers (it's not)
   - Thinking it's integrated to replicated in-memory datastores such as
   Infinispan (it's not)

So you'd want a name that says "it's not persistent" and probably "it's
easy to set up" while not hinting in any way at efficiency or Infinispan
integration.

Some attempts (none of which is perfect, but what is? :) ):

   - naive
   - mock
   - basic
   - jvm-heap
   - java-map (RAMDirectory does use a map to store its "RAMFiles")

The last one may be close to what we're looking for: it clearly says it's
in local RAM, and doesn't hint at Infinispan integration. Some could still
think it's a high-performance implementation, but at some point it's just
interpretation: one could just as well think "if it's so simple that it
just uses a java.util.Map, it must not be very advanced, and thus not very
efficient".


Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org

On 19 May 2017 at 09:34, Gustavo Fernandes  wrote:

> -1 to demote it to "testing"
>
> Let me show the other side of the coin :)
>
> RAMDirectory has its uses, as long as one understands its limitations. It
> is convenient for small non-persistent indexes, and last time I measured,
> it was faster to load than the FS directory.
>
> So it could be used in production (and I believe some people do), and
> renaming it to "testing" would feel a bit awkward. One example of
> production use of the RAMDirectory is the ES Percolator [1]
>
> We can always throw config errors or log WARN if someone is using "ram"
> with clustered caches on Infinispan, but if rebranding is really needed,
> I'd vote for something like "local-ram" or "local-heap".
>
> Thanks,
> Gustavo
>
> [1]
> https://github.com/elastic/elasticsearch/blob/master/
> modules/percolator/src/main/java/org/elasticsearch/percolator/
> PercolateQueryBuilder.java
>
>
>
> On Thu, May 18, 2017 at 9:32 PM, Sanne Grinovero 
> wrote:
>
> > -1 for "ephemeral" and "volatile", they are pretty much synonyms of
> > "ram" with all the same possible confusions, even to the point of
> > looking like being the recommended choice for "ephemeral class"
> > machines on openstack.
> >
> > "unreliable": it's not unrelaiable as it's actually very reliable and
> > to be recommended for testing, e.g. if you have an issue with our
> > other directories I'd love to know if you can reproduce it with this
> > one.
> >
> > I'll go with "testing". I want to be able to recommend it for testing,
> > and make it clear it's only meant for that.
> >
> >
> > On 18 May 2017 at 20:22, Gunnar Morling 
> > wrote:
> > > I'd argue you can keep the name, if it's in the test JAR. If people
> > > still use it in their production code, well...
> > >
> > > Otherwise, how about "ephemeral"?
> > >
> > > 2017-05-18 19:05 GMT+02:00 Sanne Grinovero :
> > >> On 18 May 2017 at 17:31, Gunnar Morling <
> gunnar.morl...@googlemail.com>
> > wrote:
> > >>> Can't you just move it to the test JAR if it's for testing only?
> > >>
> > >> Interesting idea, we can try that as well.
> > >>
> > >> I'd still want to set the name straight though. Let's agree on a name
> > first.
> > >>
> > >>>
> > >>> Am 18.05.2017 6:29 nachm. schrieb "Sanne Grinovero" <
> > sa...@hibernate.org>:
> > >>>
> > >>> Right technically it's not a unit test. But I'd like to focus on the
> > >>> testing aspect, as "local-ram" might still convey concepts as "fast",
> > >>> maybe even expect it to engage Infinispan's off-heap capabilities, or
> > >>> just being an option to consider for other reasons.
> > >>>
> > >>> "testing" ?
> > >>>
> > >>> On 18 May 2017 at 17:20, Adrian Nistor  wrote:
> >  I agree, but probably "unit-testing" is not such a good name either.
> >  Technically, that's a functional test.
> >  I think I like "local-ram" better, implying that it is not
> >  shared/distributed and it is also volatile.
> > 
> > 
> >  On 05/18/2017 06:07 PM, Sanne Grinovero wrote:
> > >
> > > As anyone who's bothered to read the manual knows, the "ram"
> > directory
> > > should really only be used for unit tests. The other
> implementations,
> > > while typically disk based, are also faster (memory mapped files)
> and
> > > more efficient (better locking design) so there's really no reason
> to
> > > use it, not even performance except for trivial, small, non
> important
> > > data sets.
> > >
> > > For example the Elasticsearch team is making sure of this by having
> > > totally removed the option of using the RAMDirectory - something I
> > > actually don't appreciate as our unit tests could benefit from it,
> > > having slow storage on our test environments.
> > >
> > > Tristan is reporting that the "ram" terminology is confusing
> people,
> > > not least in the Infinispan community as "RAM" might be ambiguous
> > > since everything is in memory, and people get surprised it's not
> > > repli

Re: [hibernate-dev] Introducing a new API in Hibernate Search to "sign" HTTP requests to Elasticsearch

[Yoann Rodiere]

>
> Did you instead consider to just let users provide their custom
> instance of org.elasticsearch.client.RestClient? It's still leaking an
> implementation detail of Hibernate Search, but at least it's one
> indirection less.


The only way to add AWS authentication to the RestClient is to use Apache
HTTP Client classes, so this solution would still bind users to the
implementation details. We'd just shove it under the carpet :)

Also, I'd argue this would be an even bigger implementation leak: at least
with the current solution with can switch to an alternative Elasticsearch
client, as long as we still use Apache HTTP Client. If we expose
RestClient, we're stuck with it *and* whatever underlying technologies it
uses.

On the other hand, we could ask them to
re-implement org.hibernate.search.elasticsearch.client.impl.ElasticsearchClient,
which is our own façade over the Elasticsearch client. But I find it a bit
much just to tweak some settings or to add a new authentication scheme...
On top of that, this solution would not allow multiple third-party
customizations to work well together (for instance AWS authentication
provided by us or a third party + some performance tweaking by the user)...
which is something the SPI we're planning in the PR could allow.

Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org

On 2 June 2017 at 10:30, Sanne Grinovero  wrote:

> On Fri, 2 Jun 2017, 08:56 Gunnar Morling,  wrote:
>
> > Hi,
> >
> > I find the exposure of an implementation detail (usage of Apache HTTP
> > client) of the Elasticsearch client a bit problematic. If they change
> > this to another HTTP client, our SPI would break.
> >
>
> Yes the very point of exposing that detail is the reason for this thread.
>
> Still, our SPI being guaranteed only for a minor, that gives a lot of
> flexibility?
>
> The Elasticsearch client exposing this itself, I don't expect them to
> switch implementation in a micro release to make some bugfix. If they
> change it in a major or even minor version, we're ok to not support that
> version until our next minor.
>
>
>
> > Did you instead consider to just let users provide their custom
> > instance of org.elasticsearch.client.RestClient? It's still leaking an
> > implementation detail of Hibernate Search, but at least it's one
> > indirection less.
> >
> > People wishing to have a custom RestClient would have to implement a
> > few more bits themselves (the logic from
> > DefaultElasticsearchClientFactory#customizeHttpClientConfig()), but
> > I'd find that acceptable for the sake of a less detail-exposing SPI,
> > plus it grants more flexibility in terms of configuring the
> > RestClient.
> >
>
>
> N.B. The client factory already is a Service so any advanced user already
> can override it.
>
> We want to make it easier for cloud users. Focusing on AWS now as we've had
> user requests for this - not least our own CI - but I'd expect other clouds
> to have similar features (today or tomorrow). I just don't expect other use
> cases to need this so we might provide them all eventually, but at this
> point my goal is to leave an appealing SPI for contributors to join on
> that.
>
> With that I mean:
> 1# this might evolve but we need something simple to use for people to not
> get stuck.
> 2# I expect integrator implementors to contribute them back
> 3# People won't have this low level dependency in their projects for long
>
> Having them re-implement the client wouldn't encourage this ;)
>
> Thanks!
> Sanne
>
>
> > --Gunnar
> >
> >
> > 2017-06-01 19:11 GMT+02:00 Sanne Grinovero :
> > > Yoann has been working on allowing Hibernate Search users to use
> > > Elasticsearch on AWS.
> > >
> > > Specifically on AWS the Elasticsearch security can be configured to
> > > use application identities, which implies the requests need to be
> > > signed.
> > >
> > > A good background read can be found here [1].
> > >
> > > We planned to allow people to use this but were not planning to
> > > include AWS specific libraries as dependencies - but since Yoann
> > > implemented an actual AWS signer in the tests I suppose it would be
> > > selfish to not ship it..
> > >
> > > Please see the API proposal on github (with the PR):
> > >  - https://github.com/hibernate/hibernate-search/pull/1426
> > >
> > > Thanks,
> > > Sanne
> > >
> > > [1] -
> > https://aws.amazon.com/blogs/security/how-to-control-
> access-to-your-amazon-elasticsearch-service-domain/
> > > ___
> > > hibernate-dev mailing list
> > > hibernate-dev@lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Introducing a new API in Hibernate Search to "sign" HTTP requests to Elasticsearch

[Yoann Rodiere]

> There's an important difference: one exposes Apache HTTP client in
> HSEARCH's SPI, whereas the other just requires usage of Apache HTTP
> client within one specific implementation. For users it doesn't change
> much, but the latter is cleaner from HSEARCH's perspective.

RestClient is not an interface, it's an implementation. There's no
interface. So yes, we would just be exposing Apache HTTP Client on top of
RestClient.

> I'm not quite following on that. If people are in control of the
> RestClient entirely, they can do whatever they want?

As mentioned above, exposing RestClient is even worse than just exposing
the Apache HTTP client.
So I was suggesting to use a proper abstraction, namely our own interface,
org.hibernate.search.elasticsearch.client.impl.ElasticsearchClient.

I suppose your remark concerned this paragraph:

> On top of that, this solution would not allow multiple third-party
> customizations to work well together (for instance AWS authentication
> provided by us or a third party + some performance tweaking by the
user)...
> which is something the SPI we're planning in the PR could allow.

If we did allow users to re-implement ElasticsearchClient, yes, one
implementor would be able to do whatever he wants... if he re-implements
it. He wouldn't be able to re-use other extensions.
Take for example the AWS authentication. You're suggestion that we provide
an alternative client allowing to connect to AWS. Fine, we do that, and
users can use it. But what if a users wants AWS authentication *and* say,
configure a proxy? Then he can't reuse our AWS client, since this client is
just an implementation of ElasticsearchClient, and we don't want to expose
anything related to Apache HTTP Client. So he must implement AWS
authentication. Just to configure a proxy.

The thing is, there are tons of things a user may want to do with Apache
HTTP Client, and we can't possibly provide access to each and every option
through an abstraction layer. So at *some* point, if we want to allow
configuration (and in the case of an HTTP client, I'm afraid we have to),
we'll have to expose internals. We just have to make sure this is done in a
controlled way (expose as little as possible).



Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org

On 2 June 2017 at 12:26, Gunnar Morling  wrote:

> 2017-06-02 11:58 GMT+02:00 Yoann Rodiere :
> >> Did you instead consider to just let users provide their custom
> >> instance of org.elasticsearch.client.RestClient? It's still leaking an
> >> implementation detail of Hibernate Search, but at least it's one
> >> indirection less.
> >
> >
> > The only way to add AWS authentication to the RestClient is to use Apache
> > HTTP Client classes, so this solution would still bind users to the
> > implementation details. We'd just shove it under the carpet :)
>
> There's an important difference: one exposes Apache HTTP client in
> HSEARCH's SPI, whereas the other just requires usage of Apache HTTP
> client within one specific implementation. For users it doesn't change
> much, but the latter is cleaner from HSEARCH's perspective.
> >
> > Also, I'd argue this would be an even bigger implementation leak: at
> least
> > with the current solution with can switch to an alternative Elasticsearch
> > client, as long as we still use Apache HTTP Client. If we expose
> RestClient,
> > we're stuck with it and whatever underlying technologies it uses.
> >
> > On the other hand, we could ask them to re-implement
> > org.hibernate.search.elasticsearch.client.impl.ElasticsearchClient,
> which is
> > our own façade over the Elasticsearch client. But I find it a bit much
> just
> > to tweak some settings or to add a new authentication scheme...
> > On top of that, this solution would not allow multiple third-party
> > customizations to work well together (for instance AWS authentication
> > provided by us or a third party + some performance tweaking by the
> user)...
> > which is something the SPI we're planning in the PR could allow.
>
> I'm not quite following on that. If people are in control of the
> RestClient entirely, they can do whatever they want?
>
> >
> > Yoann Rodière
> > Hibernate NoORM Team
> > yo...@hibernate.org
> >
> > On 2 June 2017 at 10:30, Sanne Grinovero  wrote:
> >>
> >> On Fri, 2 Jun 2017, 08:56 Gunnar Morling,  wrote:
> >>
> >> > Hi,
> >> >
> >> > I find the exposure of an implementation detail (usage of Apache HTTP
> >> > client) of the Elasticsearch client a bit problematic. If they change
> >> 

Re: [hibernate-dev] Introducing a new API in Hibernate Search to "sign" HTTP requests to Elasticsearch

[Yoann Rodiere]

> There's no exposure of HTTP Client in this SPI. Yes, if people need to
> customize the HTTP client to be used by the returned RestClient
> instance, they'll naturally depend on that. But this SPI isn't tied to
> such detail of how RestClient works - if ES folks decided to use
> OkHttp instead, our SPI contract won't be affected (of course user's
> implementations will need to change if they were customizing the HTTP
> client before).

I would feel dishonest arguing this to users... Frankly, there's little
point in returning a custom RestClient without customizing stuff related to
Apache HTTP Client. See RestClientBuilder: apart from methods tied to
Apache HTTP Client, and from options already provided by Hibernate Search,
you only have access to these:

   - org.elasticsearch.client.RestClientBuilder.setDefaultHeaders(Header[])
   -
   
org.elasticsearch.client.RestClientBuilder.setFailureListener(FailureListener)
   - org.elasticsearch.client.RestClientBuilder.setPathPrefix(String)

... and that's all.

So yes, this SPI doesn't have a *direct* dependency to Apache HTTP Client,
but any practical use of it will have one. At the end of the day, that's
what really matters, right?

Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org

On 2 June 2017 at 14:25, Gunnar Morling  wrote:

> 2017-06-02 12:49 GMT+02:00 Yoann Rodiere :
> >> There's an important difference: one exposes Apache HTTP client in
> >> HSEARCH's SPI, whereas the other just requires usage of Apache HTTP
> >> client within one specific implementation. For users it doesn't change
> >> much, but the latter is cleaner from HSEARCH's perspective.
> >
> > RestClient is not an interface, it's an implementation. There's no
> > interface. So yes, we would just be exposing Apache HTTP Client on top of
> > RestClient.
> >
>
> Here's what I'd have done:
>
> package org.hibernate.search.elasticsearch.client.spi;
>
> public interface RestClientFactory  {
> RestClient buildRestClient(SomeContext ctx);
> }
>
> There's no exposure of HTTP Client in this SPI. Yes, if people need to
> customize the HTTP client to be used by the returned RestClient
> instance, they'll naturally depend on that. But this SPI isn't tied to
> such detail of how RestClient works - if ES folks decided to use
> OkHttp instead, our SPI contract won't be affected (of course user's
> implementations will need to change if they were customizing the HTTP
> client before).
>
> >> I'm not quite following on that. If people are in control of the
> >> RestClient entirely, they can do whatever they want?
> >
> > As mentioned above, exposing RestClient is even worse than just exposing
> the
> > Apache HTTP client.
>
> I don't think it's worse, it's better actually. It just exposes our
> direct dependency in the SPI and not any of its details.
>
> > So I was suggesting to use a proper abstraction, namely our own
> interface,
> > org.hibernate.search.elasticsearch.client.impl.ElasticsearchClient.
> >
> > I suppose your remark concerned this paragraph:
> >
> >> On top of that, this solution would not allow multiple third-party
> >> customizations to work well together (for instance AWS authentication
> >> provided by us or a third party + some performance tweaking by the
> >> user)...
> >> which is something the SPI we're planning in the PR could allow.
> >
> > If we did allow users to re-implement ElasticsearchClient, yes, one
> > implementor would be able to do whatever he wants... if he re-implements
> it.
> > He wouldn't be able to re-use other extensions.
> > Take for example the AWS authentication. You're suggestion that we
> provide
> > an alternative client allowing to connect to AWS. Fine, we do that, and
> > users can use it. But what if a users wants AWS authentication and say,
> > configure a proxy? Then he can't reuse our AWS client, since this client
> is
> > just an implementation of ElasticsearchClient, and we don't want to
> expose
> > anything related to Apache HTTP Client. So he must implement AWS
> > authentication. Just to configure a proxy.
> >
> > The thing is, there are tons of things a user may want to do with Apache
> > HTTP Client, and we can't possibly provide access to each and every
> option
> > through an abstraction layer.
>
> Right, hence I wouldn't bother to do that in the first place. Just let
> users customize how RestClient is instantiated. Let's them do all they
> want. We can provide exa

Re: [hibernate-dev] Introducing a new API in Hibernate Search to "sign" HTTP requests to Elasticsearch

[Yoann Rodiere]

I made a mistake, Header is an Apache HTTP Client type and FailureListener
depends on one. So we're down to one useful customization, which we should
probably support as an Hibernate Search option by the way:

   - org.elasticsearch.client.RestClientBuilder.setPathPrefix(String)


Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org

On 2 June 2017 at 14:47, Yoann Rodiere  wrote:

> > There's no exposure of HTTP Client in this SPI. Yes, if people need to
> > customize the HTTP client to be used by the returned RestClient
> > instance, they'll naturally depend on that. But this SPI isn't tied to
> > such detail of how RestClient works - if ES folks decided to use
> > OkHttp instead, our SPI contract won't be affected (of course user's
> > implementations will need to change if they were customizing the HTTP
> > client before).
>
> I would feel dishonest arguing this to users... Frankly, there's little
> point in returning a custom RestClient without customizing stuff related to
> Apache HTTP Client. See RestClientBuilder: apart from methods tied to
> Apache HTTP Client, and from options already provided by Hibernate Search,
> you only have access to these:
>
>- org.elasticsearch.client.RestClientBuilder.
>setDefaultHeaders(Header[])
>- org.elasticsearch.client.RestClientBuilder.setFailureListener(
>FailureListener)
>- org.elasticsearch.client.RestClientBuilder.setPathPrefix(String)
>
> ... and that's all.
>
> So yes, this SPI doesn't have a *direct* dependency to Apache HTTP
> Client, but any practical use of it will have one. At the end of the day,
> that's what really matters, right?
>
> Yoann Rodière
> Hibernate NoORM Team
> yo...@hibernate.org
>
> On 2 June 2017 at 14:25, Gunnar Morling  wrote:
>
>> 2017-06-02 12:49 GMT+02:00 Yoann Rodiere :
>> >> There's an important difference: one exposes Apache HTTP client in
>> >> HSEARCH's SPI, whereas the other just requires usage of Apache HTTP
>> >> client within one specific implementation. For users it doesn't change
>> >> much, but the latter is cleaner from HSEARCH's perspective.
>> >
>> > RestClient is not an interface, it's an implementation. There's no
>> > interface. So yes, we would just be exposing Apache HTTP Client on top
>> of
>> > RestClient.
>> >
>>
>> Here's what I'd have done:
>>
>> package org.hibernate.search.elasticsearch.client.spi;
>>
>> public interface RestClientFactory  {
>> RestClient buildRestClient(SomeContext ctx);
>> }
>>
>> There's no exposure of HTTP Client in this SPI. Yes, if people need to
>> customize the HTTP client to be used by the returned RestClient
>> instance, they'll naturally depend on that. But this SPI isn't tied to
>> such detail of how RestClient works - if ES folks decided to use
>> OkHttp instead, our SPI contract won't be affected (of course user's
>> implementations will need to change if they were customizing the HTTP
>> client before).
>>
>> >> I'm not quite following on that. If people are in control of the
>> >> RestClient entirely, they can do whatever they want?
>> >
>> > As mentioned above, exposing RestClient is even worse than just
>> exposing the
>> > Apache HTTP client.
>>
>> I don't think it's worse, it's better actually. It just exposes our
>> direct dependency in the SPI and not any of its details.
>>
>> > So I was suggesting to use a proper abstraction, namely our own
>> interface,
>> > org.hibernate.search.elasticsearch.client.impl.ElasticsearchClient.
>> >
>> > I suppose your remark concerned this paragraph:
>> >
>> >> On top of that, this solution would not allow multiple third-party
>> >> customizations to work well together (for instance AWS authentication
>> >> provided by us or a third party + some performance tweaking by the
>> >> user)...
>> >> which is something the SPI we're planning in the PR could allow.
>> >
>> > If we did allow users to re-implement ElasticsearchClient, yes, one
>> > implementor would be able to do whatever he wants... if he
>> re-implements it.
>> > He wouldn't be able to re-use other extensions.
>> > Take for example the AWS authentication. You're suggestion that we
>> provide
>> > an alternative client allowing to connect to AWS. Fine, we do that, and
>> > users can use it. But what if

Re: [hibernate-dev] Introducing a new API in Hibernate Search to "sign" HTTP requests to Elasticsearch

[Yoann Rodiere]

> What's the benefit of this catch-up game?

Not tainting our SPI with RestClient :)

Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org

On 2 June 2017 at 14:59, Gunnar Morling  wrote:

> Sure, as I said, an implementor of that SPI will very likely deal with
> the HTTP client. But our SPI isn't tainted by that.
>
> I also don't see much value in re-defining all the options from
> RestClientBuilder. ElasticsearchHttpClientConfigurer resembles
> HttpClientConfigCallback. Would you also re-define
> RequestConfigCallback? What if new options get added to
> RestClientBuilder? What's the benefit of this catch-up game?
>
>
>
>
> 2017-06-02 14:47 GMT+02:00 Yoann Rodiere :
> >> There's no exposure of HTTP Client in this SPI. Yes, if people need to
> >> customize the HTTP client to be used by the returned RestClient
> >> instance, they'll naturally depend on that. But this SPI isn't tied to
> >> such detail of how RestClient works - if ES folks decided to use
> >> OkHttp instead, our SPI contract won't be affected (of course user's
> >> implementations will need to change if they were customizing the HTTP
> >> client before).
> >
> > I would feel dishonest arguing this to users... Frankly, there's little
> > point in returning a custom RestClient without customizing stuff related
> to
> > Apache HTTP Client. See RestClientBuilder: apart from methods tied to
> Apache
> > HTTP Client, and from options already provided by Hibernate Search, you
> only
> > have access to these:
> >
> > org.elasticsearch.client.RestClientBuilder.setDefaultHeaders(Header[])
> > org.elasticsearch.client.RestClientBuilder.setFailureListener(
> FailureListener)
> > org.elasticsearch.client.RestClientBuilder.setPathPrefix(String)
> >
> > ... and that's all.
> >
> > So yes, this SPI doesn't have a direct dependency to Apache HTTP Client,
> but
> > any practical use of it will have one. At the end of the day, that's what
> > really matters, right?
> >
> > Yoann Rodière
> > Hibernate NoORM Team
> > yo...@hibernate.org
> >
> > On 2 June 2017 at 14:25, Gunnar Morling  wrote:
> >>
> >> 2017-06-02 12:49 GMT+02:00 Yoann Rodiere :
> >> >> There's an important difference: one exposes Apache HTTP client in
> >> >> HSEARCH's SPI, whereas the other just requires usage of Apache HTTP
> >> >> client within one specific implementation. For users it doesn't
> change
> >> >> much, but the latter is cleaner from HSEARCH's perspective.
> >> >
> >> > RestClient is not an interface, it's an implementation. There's no
> >> > interface. So yes, we would just be exposing Apache HTTP Client on top
> >> > of
> >> > RestClient.
> >> >
> >>
> >> Here's what I'd have done:
> >>
> >> package org.hibernate.search.elasticsearch.client.spi;
> >>
> >> public interface RestClientFactory  {
> >> RestClient buildRestClient(SomeContext ctx);
> >> }
> >>
> >> There's no exposure of HTTP Client in this SPI. Yes, if people need to
> >> customize the HTTP client to be used by the returned RestClient
> >> instance, they'll naturally depend on that. But this SPI isn't tied to
> >> such detail of how RestClient works - if ES folks decided to use
> >> OkHttp instead, our SPI contract won't be affected (of course user's
> >> implementations will need to change if they were customizing the HTTP
> >> client before).
> >>
> >> >> I'm not quite following on that. If people are in control of the
> >> >> RestClient entirely, they can do whatever they want?
> >> >
> >> > As mentioned above, exposing RestClient is even worse than just
> exposing
> >> > the
> >> > Apache HTTP client.
> >>
> >> I don't think it's worse, it's better actually. It just exposes our
> >> direct dependency in the SPI and not any of its details.
> >>
> >> > So I was suggesting to use a proper abstraction, namely our own
> >> > interface,
> >> > org.hibernate.search.elasticsearch.client.impl.ElasticsearchClient.
> >> >
> >> > I suppose your remark concerned this paragraph:
> >> >
> >> >> On top of that, this solution would not allow multiple third-party
> >> >> customizations to work well

Re: [hibernate-dev] Introducing a new API in Hibernate Search to "sign" HTTP requests to Elasticsearch

[Yoann Rodiere]

> Anyways, I've had my say :)

And I'm grateful you took the time to do it. I guess we both would have
preferred to agree on the same solution, but... at least we now have
something to process.

Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org

On 2 June 2017 at 15:11, Gunnar Morling  wrote:

> I reckon you are making fun of me. Anyways, I've had my say :)
>
> 2017-06-02 15:03 GMT+02:00 Yoann Rodiere :
> >> What's the benefit of this catch-up game?
> >
> > Not tainting our SPI with RestClient :)
> >
> > Yoann Rodière
> > Hibernate NoORM Team
> > yo...@hibernate.org
> >
> > On 2 June 2017 at 14:59, Gunnar Morling  wrote:
> >>
> >> Sure, as I said, an implementor of that SPI will very likely deal with
> >> the HTTP client. But our SPI isn't tainted by that.
> >>
> >> I also don't see much value in re-defining all the options from
> >> RestClientBuilder. ElasticsearchHttpClientConfigurer resembles
> >> HttpClientConfigCallback. Would you also re-define
> >> RequestConfigCallback? What if new options get added to
> >> RestClientBuilder? What's the benefit of this catch-up game?
> >>
> >>
> >>
> >>
> >> 2017-06-02 14:47 GMT+02:00 Yoann Rodiere :
> >> >> There's no exposure of HTTP Client in this SPI. Yes, if people need
> to
> >> >> customize the HTTP client to be used by the returned RestClient
> >> >> instance, they'll naturally depend on that. But this SPI isn't tied
> to
> >> >> such detail of how RestClient works - if ES folks decided to use
> >> >> OkHttp instead, our SPI contract won't be affected (of course user's
> >> >> implementations will need to change if they were customizing the HTTP
> >> >> client before).
> >> >
> >> > I would feel dishonest arguing this to users... Frankly, there's
> little
> >> > point in returning a custom RestClient without customizing stuff
> related
> >> > to
> >> > Apache HTTP Client. See RestClientBuilder: apart from methods tied to
> >> > Apache
> >> > HTTP Client, and from options already provided by Hibernate Search,
> you
> >> > only
> >> > have access to these:
> >> >
> >> > org.elasticsearch.client.RestClientBuilder.
> setDefaultHeaders(Header[])
> >> >
> >> > org.elasticsearch.client.RestClientBuilder.setFailureListener(
> FailureListener)
> >> > org.elasticsearch.client.RestClientBuilder.setPathPrefix(String)
> >> >
> >> > ... and that's all.
> >> >
> >> > So yes, this SPI doesn't have a direct dependency to Apache HTTP
> Client,
> >> > but
> >> > any practical use of it will have one. At the end of the day, that's
> >> > what
> >> > really matters, right?
> >> >
> >> > Yoann Rodière
> >> > Hibernate NoORM Team
> >> > yo...@hibernate.org
> >> >
> >> > On 2 June 2017 at 14:25, Gunnar Morling  wrote:
> >> >>
> >> >> 2017-06-02 12:49 GMT+02:00 Yoann Rodiere :
> >> >> >> There's an important difference: one exposes Apache HTTP client in
> >> >> >> HSEARCH's SPI, whereas the other just requires usage of Apache
> HTTP
> >> >> >> client within one specific implementation. For users it doesn't
> >> >> >> change
> >> >> >> much, but the latter is cleaner from HSEARCH's perspective.
> >> >> >
> >> >> > RestClient is not an interface, it's an implementation. There's no
> >> >> > interface. So yes, we would just be exposing Apache HTTP Client on
> >> >> > top
> >> >> > of
> >> >> > RestClient.
> >> >> >
> >> >>
> >> >> Here's what I'd have done:
> >> >>
> >> >> package org.hibernate.search.elasticsearch.client.spi;
> >> >>
> >> >> public interface RestClientFactory  {
> >> >> RestClient buildRestClient(SomeContext ctx);
> >> >> }
> >> >>
> >> >> There's no exposure of HTTP Client in this SPI. Yes, if people need
> to
> >> >> customize the HTTP client to be used by the returned RestClient
> >> >> instance, they'll naturally depend on

Re: [hibernate-dev] Let's avoid @hsearch.experimental javadoc tags in SPI

[Yoann Rodiere]

Hi,

Answers below.

Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org

On 6 June 2017 at 18:48, Sanne Grinovero  wrote:

> == SPI have very long guarantees, anyway
>
> Considering that an SPI contract has relatively low SLAs I'd like to
> be way more "aggressive" in the removal of "this is experimental"
> notices.
>
> I'd also ask you all to consider not marking them as such, especially
> if the issue at hand feels properly sorted out.
>
> Most typically we'll have a notice like "This contract is currently
> under active development ".
>
> Anything which is marked as such and yet has not changed since the
> last minor release should no longer qualify as "active development",
> so we should clean it up and avoid scaring away potential users for no
> reason.
>
> WDYT?
>

Sure, it makes sense if we don't provide any long-term guarantee of
backward compatibility.


> == What about API ?
>
> I am going to propose cleaning up the "experimental" tag from some
> selected APIs as well, yet in that case I don't think we should apply
> a similar reasoning as SPI (development activity) as time is not the
> right indicator.
>
> Some API has been marked experimental for a long time for good
> reasons: we might not have had the bandwidth (or interest) of
> finishing some related issue which could be essential for the feature
> to be actually used, and it might be problematic to fix such an half
> baked feature w/o being ale to make changes in the contract.
>

Yes. This basically means we don't have a solution for APIs, but... at
least we're aware of that :)


> == Reminder on changes
>
> Since we're on the subject... the API/SPI/impl classification is not
> black and white so bear in mind that any change we make will annoy
> someone.
>
> It's a tradeoff, but when you're making *any* change and have the
> opportunity to keep the contract backwards compatible, consider doing
> so. @Deprecated is a nice annotation.
> Of course this is not a reaction on any specific change; if any I'm
> just uncomfortable that I'm going to break a lot myself, and my own
> experience is that one can deal with some limited amount of
> compilation|compatibility issues but if we push too many "SPI & SPI-
> changes" in a single release people will get stuck on the older
> versions.
>

I agree with your analysis, but I'm not sure being aware of it and agreeing
that we shouldn't break too much will solve the problem. To me, a big part
of why we have a risk of breaking lots of things is that we currently don't
have the big picture until we write up the migration guide, just before we
release.
Maybe a way to solve the issue would be to write the migration guide
incrementally, with each PR we send?

One way of enforcing this (reminding us to update the migration guide)
would be to have a tool check for API/SPI breaks on *each build*, and make
the build fail by default for any API/SPI change, requiring to at least put
an exclusion in a dedicated file to make it pass. Unless I'm wrong we
currently only do this in the engine/ORM modules. And actually I'm not sure
the current setup works, because I remember breaking SPIs since 5.7 and I
never had any build error relative to SPI breaks...
Anyway, if you agree with that, I can have a look at the tooling we may
use. I suspect other Hibernate projects may already have such tooling in
place (Hibernate Validator in particular).


>
> We need to enable people to iterate in smaller milestones which are
> simpler to handle; if we're doing too much let's just make more
> intermediate minor releases.
>

If I remember correctly, that's exactly what we intended to do with 5.8,
except it's beginning to be a rather large intermediate minor itself :D
More seriously, yes, we should probably put less in each release, and in
particular have safeguards so that we don't realize there's too much in a
release when it's too late. But in order to do that, we should (in my
opinion) also have stricter monitoring of our work, and that's probably not
something we want, for various reasons we already discussed (one of them
being that we don't always know expansive and API/SPI-breaking a task will
be before we actually work on it).



>
> Thanks!
> Sanne
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate Search 5.8.0.Beta3 released

[Yoann Rodiere]

Hello,

We just released Hibernate Search 5.8.0.Beta3, with easier analyzer
configuration, AWS compatibility and DI integration.

You can find more information about 5.8.0.Beta3 on our blog:

http://in.relation.to/2017/06/13/hibernate-search-5-8-0-Beta3/

Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate Search 5.8.0.Beta4 released

[Yoann Rodiere]

Hello,

We just released Hibernate Search 5.8.0.Beta4, with AWS integration and
various bugfixes.
We expect this to be the last 5.8.0 Beta, so be sure to check it out and
give us some feedback before the feature freeze!

You can find more information about 5.8.0.Beta4 on our blog:

http://in.relation.to/2017/07/18/hibernate-search-5-8-0-Beta4/

Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [HV] Hibernate Validator 6 benchmark updates

[Yoann Rodiere]

Kudos to you! I'm slowly beginning to understand what a pain such work can
be... Nice to have a reminder that this work can ultimately be rewarded ;)

Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org

On 19 July 2017 at 16:44, Guillaume Smet  wrote:

> Hi,
>
> So, as we are leaning towards final, I made another round of benchmarking
> on HV 6.
>
> They are run on the same machine as the previous "Hibernate Validator 6
> benchmarks results" I posted a few months ago [1] so they can be compared
> to these numbers (you'll notice the 5.4.1 numbers are about the same
> between the 2 emails).
>
> Note that these benchmarks only exercises the validation engine but does
> not report any violation.
>
> I think I'll add some more benchmarks to ensure violation reporting also
> moves in the right direction.
>
> It might also be a good occasion to revisit this benchmark:
> http://carinae.net/2010/06/benchmarking-hibernate-validator-and-apache-
> beanvalidation-the-two-jsr-303-implementations/
> . With a large value of "revisit" as it's really basic but the scenarios
> are interesting. Note that I'm a bit pessimistic on the parsing part: we
> now do a lot more work than before to deal with container elements so the
> startup cost will probably be significantly higher.
>
> == Apache BVal 1.1.2
>
> Result
> "org.hibernate.validator.performance.simple.SimpleValidation.
> testSimpleBeanValidation":
>   357.500 ±(99.9%) 5.327 ops/ms [Average]
>   (min, avg, max) = (337.100, 357.500, 381.472), stdev = 10.760
>   CI (99.9%): [352.173, 362.827] (assumes normal distribution)
>
> Result
> "org.hibernate.validator.performance.cascaded.CascadedValidation.
> testCascadedValidation":
>   379.605 ±(99.9%) 5.817 ops/ms [Average]
>   (min, avg, max) = (360.654, 379.605, 411.361), stdev = 11.750
>   CI (99.9%): [373.789, 385.422] (assumes normal distribution)
>
> (not really clear how BVal happens to be faster in the cascaded validation
> case)
>
> == HV 5.4.1.Final
>
> Result
> "org.hibernate.validator.performance.simple.SimpleValidation.
> testSimpleBeanValidation":
>   558.196 ±(99.9%) 3.643 ops/ms [Average]
>   (min, avg, max) = (542.396, 558.196, 575.360), stdev = 7.360
>   CI (99.9%): [554.552, 561.839] (assumes normal distribution)
>
> Result
> "org.hibernate.validator.performance.cascaded.CascadedValidation.
> testCascadedValidation":
>   285.788 ±(99.9%) 1.970 ops/ms [Average]
>   (min, avg, max) = (278.611, 285.788, 298.530), stdev = 3.980
>   CI (99.9%): [283.817, 287.758] (assumes normal distribution)
>
> == Master from March after the first round of improvements (numbers taken
> from the previous email)
>
> Result
> "org.hibernate.validator.performance.simple.SimpleValidation.
> testSimpleBeanValidation":
>   869.546 ±(99.9%) 14.734 ops/ms [Average]
>   (min, avg, max) = (760.007, 869.546, 909.206), stdev = 29.763
>   CI (99.9%): [854.813, 884.280] (assumes normal distribution)
>
> Result
> "org.hibernate.validator.performance.cascaded.CascadedValidation.
> testCascadedValidation":
>   343.699 ±(99.9%) 2.077 ops/ms [Average]
>   (min, avg, max) = (331.333, 343.699, 352.626), stdev = 4.196
>   CI (99.9%): [341.622, 345.776] (assumes normal distribution)
>
> == HV 6 - Current master with
> https://github.com/hibernate/hibernate-validator/pull/814 applied
>
> Result
> "org.hibernate.validator.performance.simple.SimpleValidation.
> testSimpleBeanValidation":
>   924.121 ±(99.9%) 3.686 ops/ms [Average]
>   (min, avg, max) = (905.423, 924.121, 941.295), stdev = 7.446
>   CI (99.9%): [920.435, 927.807] (assumes normal distribution)
>
> Result
> "org.hibernate.validator.performance.cascaded.CascadedValidation.
> testCascadedValidation":
>   430.092 ±(99.9%) 3.661 ops/ms [Average]
>   (min, avg, max) = (416.439, 430.092, 447.607), stdev = 7.396
>   CI (99.9%): [426.431, 433.754] (assumes normal distribution)
>
> == Conclusion
>
> The good news is that the results are even better than the ones from March,
> after some further tweaking.
>
> We are significantly faster than BVal in these scenarios and also
> significantly faster than 5.4.1.Final.
>
> Now, we need to get this PR in :).
>
> [1] http://lists.jboss.org/pipermail/hibernate-dev/2017-March/016057.html
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Stuck build on CI

[Yoann Rodiere]

> This build on CI seems stuck since yesterday:

Yes, there was a race condition that I fixed before leaving on Friday.
Sorry I didn't realize this build was still running.

> Also I noticed a huge amount of log output: "121,741 KB". Do you really
> need all that output for each build? Esp. given that this job is about
> perf, logging that much seems concerning potentially.

No we don't need that much output, but fortunately we don't usually get
that much output. It's only because JMH interrupted all threads when
benchmarks timed out, which made bulk requests fail, which means the bulk
requests were printed out as part of the stack trace. And since you've got
250 requests per bulk requests, that's a lot.
Not sure it's worth it to tune the test so that we don't get that much
output when failing though, since obviously performance tests shouldn't
fail that hard if I did my work correctly.
I'll add a ticket about adding a special case for logging interrupted
requests, though, because users may very well end up in a similar situation
if they want to stop their application by sending out thread interrupts.


Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org

On 23 July 2017 at 09:52, Gunnar Morling  wrote:

> Hi Sanne, Yoann,
>
> This build on CI seems stuck since yesterday:
>
>
> http://ci.hibernate.org/job/hibernate-search-performance-elasticsearch/44/
>
> Also I noticed a huge amount of log output: "121,741 KB". Do you really
> need all that output for each build? Esp. given that this job is about
> perf, logging that much seems concerning potentially.
>
> Cheers,
>
> --Gunnar
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate Search 5.8.0.CR1 released

[Yoann Rodiere]

Hello,

We just released Hibernate Search 5.8.0.CR1, with performance improvements
and various bugfixes.
This is the last step before 5.8 is released. Be sure to check it out so
you can share your thoughts with us before the release!

You can find more information about 5.8.0.CR1 on our blog:

http://in.relation.to/2017/08/16/hibernate-search-5-8-0-CR1/


Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Bugfix releases for Hibernate Search 5.5, 5.6 and 5.7

[Yoann Rodiere]

Hi all,

We just published three bugfix releases of Hibernate Search: 5.5.8.Final,
5.6.3.Final and 5.7.2.Final.

Please see the blog for more details:
http://in.relation.to/2017/08/24/hibernate-search-5-5-8-and-5-6-3-and-5-7-2/

Thanks,

Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] ETA Hibernate-ORM 5.2.11 release?

[Yoann Rodiere]

Hi Gail,

We have a fix on the Hibernate Search side and I confirmed the fix should
not involve any retro-compatibility issue, so we can treat this issue as
non-blocking for the ORM release.

Thanks,

Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org

On 4 September 2017 at 14:23, Guillaume Smet 
wrote:

> Gail,
>
> Thanks for your insight. Yoann confirmed it's a Search issue previously
> hidden by the previous ORM behavior.
>
> He's working on a fix.
>
> On my side, I submitted all the PRs I had in mind for 5.2.11. There is
> still https://github.com/hibernate/hibernate-orm/pull/1998 that should be
> reviewed (I think it's really nice to have for the users so that they don't
> face weird deprecation warnings on things that shouldn't be deprecated).
>
> --
> Guillaume
>
> On Thu, Aug 31, 2017 at 8:44 PM, Gail Badner  wrote:
>
>> Guillaume and Yoann,
>>
>> FYI, I took a look and added a comment to  https://hibernate.atlassia
>> n.net/browse/HSEARCH-2865.
>>
>> Regards,
>> Gail
>>
>> On Thu, Aug 31, 2017 at 9:07 AM, Guillaume Smet > > wrote:
>>
>>> Gail,
>>>
>>> FWIW, I also discovered https://hibernate.atlassian.ne
>>> t/browse/HSEARCH-2865 today. Let's be sure it's not an ORM issue before
>>> releasing 5.2.11.Final.
>>>
>>> Yoann is going to take a look at it on Monday so we should be fixed soon.
>>>
>>> --
>>> Guillaume
>>>
>>> On Wed, Aug 30, 2017 at 4:48 PM, Guillaume Smet <
>>> guillaume.s...@gmail.com> wrote:
>>>
 Hi,

 FYI, I posted the last PR of the OGM series today:
 https://github.com/hibernate/hibernate-orm/pull/1997 .

 I expect some discussion about it in the next few days as it's not that
 straightforward.

 --
 Guillaume

 On Fri, Aug 25, 2017 at 7:24 PM, Gail Badner 
 wrote:

> That's fine. I can wait for you to finish. Let me know when you're
> done with what you need to do.
>
> On Fri, Aug 25, 2017 at 6:18 AM, Guillaume Smet <
> guillaume.s...@gmail.com> wrote:
>
>> On Wed, Aug 23, 2017 at 8:46 PM, Gail Badner 
>> wrote:
>>
>>> I can do it next week. I've tentatively set the release date for
>>> Wednesday, 8/30.
>>>
>>> Guillaume, does that give you enough time to make your changes?
>>>
>>
>> I'm expecting discussions on one of the patch I want to submit so not
>> sure we'll be able to cut it off on Wednesday.
>>
>> Still struggling with getting all our OGM tests to pass but I have
>> good hope I will be able to send the ORM patches soon.
>>
>> --
>> Guillaume
>>
>>
>

>>>
>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [Search and more] What is new in a give release

[Yoann Rodiere]

Hey,

About Search, true, the information is somewhat hidden in many blog posts.
I'm not sure the roadmap is the right place, though, since we probably want
the format to be different for past and future releases: information for
past releases is typically more precise and more verbose, with code
examples and so on. See for instance this blog post: http://in.relation.to/
2017/06/13/hibernate-search-5-8-0-Beta3/ . I'm afraid the future roadmap
would be drowned in the past releases.

I was thinking about another problem: we don't have a compatibility matrix.
We only have a few dependencies (mainly ORM and Lucene), but it's really
hard to know which versions of the dependencies to use with which version
of Search, and users frequently use the wrong versions.
With that in mind, I would rather see a "Versions" page, with a summary at
the top (including a one-liner for each minor and the compatibilty matrix),
and one section for each minor (with anchors, so that we can link to them
from other pages such as the downloads). Or maybe even one page for the
detail of each minor, if there's too much text.
I think it would make sense to have all that information gathered in a
single place, because all of that is needed for users to pick the version
they want: they need to know the benefits of upgrading (features) but also
the constraints (compatibility matrix).
Maybe I can give it a try at the end of the week?


Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org

On 6 September 2017 at 09:21, Emmanuel Bernard 
wrote:

> Hey all,
>
> I was trying to answer the following question, what is roughly new between
> 5.6, 5.7 and 5.8 (minor releases)?
>
> My first reflex was to go to http://hibernate.org/search/downloads/ <
> http://hibernate.org/search/downloads/> to read about the onliner per
> release. Except it’s a onliner per micro release and “minor adjustments”
> for 5.6.3.Final gave me literally no info whatsoever.
>
> My second reflex was to go to http://hibernate.org/search/roadmap/ <
> http://hibernate.org/search/roadmap/> to find a historical entry about
> older versions and the main changes in bullet points. No luck. It only
> talks about the future.
>
> My third reflex was to go to http://in.relation.to/hibernate-search/ <
> http://in.relation.to/hibernate-search/> I ended up giving up midway page
> 2 of the list of blog entries. It’s a mix of simultaneous parallel releases
> with what’s new since the last CR or the last micro kind of reports and
> gave up in dismay at the energy I would have to spend to extract what’s new
> for a full minor release.
>
> I did exaggerate a bit the third point but I did give up. We need
> somewhere a summary page of what’s new per minor releases. I think the
> roadmap page could be the host.
> Likewise, we might need a oneliner entry in the download section (per
> release) that points to this minor release summary.
>
> Thoughts?
>
> Speaking of roadmap:
> - HV roadmap is massively out of date
> - OGM is lying a bit on the future but at least has the past summary I was
> talking about
> - Search has a good future roadmap but no past
>
> Emmanuek
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [Search and more] What is new in a give release

[Yoann Rodiere]

Hey,

I pushed an update to staging. I only converted the "Search" part for now.
What changes:

   - The _data folder structured changed a bit, so that we can introduces a
   YAML file for each series (5.5, 5.6, 5.6, 5.8, ...), containing a summary
   of this series and a list of integration constraints (ORM > 5.2, etc.)
   - The "Downloads" page is renamed to "Releases", since, well, it's about
   more than just downloads. See
   http://staging.hibernate.org/search/releases/
   - The "Releases" page now includes a "Compatibilty matrix" section based
   on the new data I mentioned above
   - The "Releases" page now includes links to one page for each series
   ("More on the 5.8 series")
   - There is now one page for each series (see
   http://staging.hibernate.org/search/releases/series/5.8/). This page
   includes:
  - A short (one-line) summary of this series
  - A reminder of the integration constraints for this series
  - A section about the main changes in this release. I only wrote
  something for the 5.8 series for now, and I basically
copy/pasted sections
  from various blog posts.
  - A list of all releases in this series.

What I didn't do, but could make sense:

   - add a sub-menu element under "Releases" for each series
   - link to the documentation for each of the latest releases from the
   "Releases" page
   - link to the latest documentation and to the migration guides from each
   series' page

What do you all think? Emmanuel, would this address your concerns? Steve,
would this be a good fit for ORM?

Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org

On 6 September 2017 at 17:16, Steve Ebersole  wrote:

> This is something I brought up ages ago wrt ORM.  I wanted something
> (although ideally integrated with the "more version friendly"
> hibernate.org design) similar to what I did atm on the ORM GitHub wiki.
> For example, for 5.2 we have:
>
>
>- https://github.com/hibernate/hibernate-orm/wiki/Roadmap5.2
>- https://github.com/hibernate/hibernate-orm/wiki/Migration-Guide---5.2
>- https://github.com/hibernate/hibernate-orm/wiki/ReleaseNotes5.2
>
>
> The format could be better and some of this information could be combined
> (release notes and migration guide e.g.).  But bear in mind that this was
> just what I put together to illustrate what I was wanted to do, generally
> speaking - so its a bit "rough"
>
>
> On Wed, Sep 6, 2017 at 4:17 AM Sanne Grinovero 
> wrote:
>
>> Thanks for that Emmanuel.
>>
>> I'll fix the one-liner describing the release, I believe we had
>> already noticed this in the past: they need to describe the whole
>> minor not the micro update.
>> The Search roadmap actually also needs a little re-touch, I'll propose
>> a PR for that too.
>>
>> Regarding past roadmaps: I don't like to clutter the roadmap page with
>> the previous copies, especially as they should have a different nature
>> of not being a plan but being a record of what was actually done.
>> Also, we did agree in past meetings to remove all the old ones. e.g.
>> we never ported the release notes for version 3.x and 4.x as back then
>> we decided this was no place for that. Happy to revisit this decision
>> but let's separate them:
>>
>> What about a "past releases" page at the same level of roadmap, and
>> linking to it both from the main Search menu and the roadmap?
>>
>> +1 for Yoann's proposal to re-introduce the compatibility matrix
>> (there was one ~6 years ago). I also had proposed to reintroduce it
>> more recently, and was not done on the grounds that it gets out of
>> date quickly.
>> Still users badly need it so unless someone has a better idea, let's
>> agree on trying to keep it up to date manually. Let's try structure it
>> in such a way that it won't need to be updated for every single
>> release.
>>
>> Thanks,
>> Sanne
>>
>>
>> On 6 September 2017 at 08:37, Yoann Rodiere  wrote:
>> > Hey,
>> >
>> > About Search, true, the information is somewhat hidden in many blog
>> posts.
>> > I'm not sure the roadmap is the right place, though, since we probably
>> want
>> > the format to be different for past and future releases: information for
>> > past releases is typically more precise and more verbose, with code
>> > examples and so on. See for instance this blog post:
>> http://in.relation.to/
>> > 2017/06/13/hibernate-search-5-8-0-Beta3/ . I'm afraid the future
>> roadmap
>> > would be drowned in the past r

Re: [hibernate-dev] [Search and more] What is new in a give release

[Yoann Rodiere]

Sanne, I addressed both your comments. Is it better?
I also addressed Guillaume's comment on HipChat, and made the compatibility
matrix a bit... fuzzier, so that we won't have to update it as often. We
can still make it very specific if we want to, but we won't be limited by
the layout anymore.

Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org

On 8 September 2017 at 15:11, Sanne Grinovero  wrote:

> Thanks Yoann!
> Looks great.
>
> Two minor suggestions:
>  - could the two links we have for each release on search/releases/ on
> two separate lines? Or something else to make it clear that there are
> two linkes.
>  - Regarding the "Compatibility matrix", the header line (the one in
> black) .. I think we need to clarify in some way that you're referring
> to Hibernate Search releases. Possibly just link to the page
> describing the family?
>
> Thanks,
> Sanne
>
>
> On 8 September 2017 at 13:53, Yoann Rodiere  wrote:
> > Hey,
> >
> > I pushed an update to staging. I only converted the "Search" part for
> now.
> > What changes:
> >
> > The _data folder structured changed a bit, so that we can introduces a
> YAML
> > file for each series (5.5, 5.6, 5.6, 5.8, ...), containing a summary of
> this
> > series and a list of integration constraints (ORM > 5.2, etc.)
> > The "Downloads" page is renamed to "Releases", since, well, it's about
> more
> > than just downloads. See http://staging.hibernate.org/search/releases/
> > The "Releases" page now includes a "Compatibilty matrix" section based on
> > the new data I mentioned above
> > The "Releases" page now includes links to one page for each series
> ("More on
> > the 5.8 series")
> > There is now one page for each series (see
> > http://staging.hibernate.org/search/releases/series/5.8/). This page
> > includes:
> >
> > A short (one-line) summary of this series
> > A reminder of the integration constraints for this series
> > A section about the main changes in this release. I only wrote something
> for
> > the 5.8 series for now, and I basically copy/pasted sections from various
> > blog posts.
> > A list of all releases in this series.
> >
> > What I didn't do, but could make sense:
> >
> > add a sub-menu element under "Releases" for each series
> > link to the documentation for each of the latest releases from the
> > "Releases" page
> > link to the latest documentation and to the migration guides from each
> > series' page
> >
> > What do you all think? Emmanuel, would this address your concerns? Steve,
> > would this be a good fit for ORM?
> >
> > Yoann Rodière
> > Hibernate NoORM Team
> > yo...@hibernate.org
> >
> > On 6 September 2017 at 17:16, Steve Ebersole 
> wrote:
> >>
> >> This is something I brought up ages ago wrt ORM.  I wanted something
> >> (although ideally integrated with the "more version friendly"
> hibernate.org
> >> design) similar to what I did atm on the ORM GitHub wiki.  For example,
> for
> >> 5.2 we have:
> >>
> >> https://github.com/hibernate/hibernate-orm/wiki/Roadmap5.2
> >> https://github.com/hibernate/hibernate-orm/wiki/Migration-Guide---5.2
> >> https://github.com/hibernate/hibernate-orm/wiki/ReleaseNotes5.2
> >>
> >>
> >> The format could be better and some of this information could be
> combined
> >> (release notes and migration guide e.g.).  But bear in mind that this
> was
> >> just what I put together to illustrate what I was wanted to do,
> generally
> >> speaking - so its a bit "rough"
> >>
> >>
> >> On Wed, Sep 6, 2017 at 4:17 AM Sanne Grinovero 
> >> wrote:
> >>>
> >>> Thanks for that Emmanuel.
> >>>
> >>> I'll fix the one-liner describing the release, I believe we had
> >>> already noticed this in the past: they need to describe the whole
> >>> minor not the micro update.
> >>> The Search roadmap actually also needs a little re-touch, I'll propose
> >>> a PR for that too.
> >>>
> >>> Regarding past roadmaps: I don't like to clutter the roadmap page with
> >>> the previous copies, especially as they should have a different nature
> >>> of not being a plan but being a record of what was actually done.
> >>> Also, we did agree in past meetings to remove all the old ones. e.g.
> >&g

Re: [hibernate-dev] [Search and more] What is new in a give release

[Yoann Rodiere]

Steve,

If I understood correctly, the main difference between what I did and what
you want is you don't want a "hub" pointing to different versions, you want
to redirect to the page for the latest version, and from there allow to
move to another version using drop-down.
While I can understand you'd want that for ORM, I'm not sure it's such a
good idea for projects such as Search or OGM, where the difference between
two families is not only about features, but also (and in some cases,
mainly) about which versions of other components it can integrate with. In
this case, I'm not sure a drop-down would be enough to guide users to the
correct version...

As for your other concerns:

   - I'll try to add a links to the "documentation" page specific to each
   series, both in the main "releases" page and in each series-specific page.
   - The list of all micro/bugfix releases is already there, at the bottom
   of the page: http://staging.hibernate.org/search/releases/5.8/
   I'll see if I can add some sort of table of contents at the top to make
   it more visible.
   - The link to the full changelog is already there, though maybe it's not
   very visible.


Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org

On 8 September 2017 at 16:05, Steve Ebersole  wrote:

> For me the real problem is that its not just Downloads/Releases that
> should be (need to be really) treated in this manner - our documentation is
> also family specific.
>
> So for ORM I had envisioned a "versions" (although "releases" works just
> as well) component to the url scheme.  Vlad did this for documentation (see
> the version drop down), but we have not yet tackled this for versions - too
> many other more pressing tasks.  Also, I am not sure yet the best overall
> structure for this - some of the project related information is not
> version-specific (FAQ, Books, Paid Support, etc) while others are.
>
> To me personally, I think the "Documentation" and
> Downloads/Versions/Releases should not be on the left nav.  Or, leave them
> on the nav and have them implicitly direct to the 
> most-recent-prod-release-family.
> But overall I had envisioned a release-specific page - specific to release
> families (5.0, 5.1, etc) as opposed to specific micro/bugfix releases
> (5.0.1, 5.0.2, etc).  This release page would include:
>
>1. General description - what were the main points or developments for
>this family?
>2. Links to its documentation
>3. List of all micro/bugfix releases as a sort-of simplified
>changelog.  This part is still unclear in my head as to the best way to
>represent this information, but ultimately each entry in this list would
>need to include:
>   1. announcement URL
>   2. sysopsis of the main fixes/changes
>   3. link to the full changelog
>
> For the most part, the information I listed for the micro/bugfix release
> entries is covered in the release announcement so one option is to simply
> link to each announcement for that family - possibly driven by the release
> yaml files.
>
> This also fixes what I find to be a very confusing list of "latest"
> releases.  I think that works much better as a single entry on the release
> family page.
>
> Will what you did "work" for ORM?  Sure.  What I describe is just what I
> personally think would be better in terms of ORM needs, but I have
> absolutely no resources to do that atm.  So for now, whatever y'all deem is
> best is probably the best way to go.
>
>
> On Fri, Sep 8, 2017 at 8:11 AM Sanne Grinovero 
> wrote:
>
>> Thanks Yoann!
>> Looks great.
>>
>> Two minor suggestions:
>>  - could the two links we have for each release on search/releases/ on
>> two separate lines? Or something else to make it clear that there are
>> two linkes.
>>  - Regarding the "Compatibility matrix", the header line (the one in
>> black) .. I think we need to clarify in some way that you're referring
>> to Hibernate Search releases. Possibly just link to the page
>> describing the family?
>>
>> Thanks,
>> Sanne
>>
>>
>> On 8 September 2017 at 13:53, Yoann Rodiere  wrote:
>> > Hey,
>> >
>> > I pushed an update to staging. I only converted the "Search" part for
>> now.
>> > What changes:
>> >
>> > The _data folder structured changed a bit, so that we can introduces a
>> YAML
>> > file for each series (5.5, 5.6, 5.6, 5.8, ...), containing a summary of
>> this
>> > series and a list of integration constraints (ORM > 5.2, etc.)
>> > The "Downloads" page is renamed

Re: [hibernate-dev] [Search and more] What is new in a give release

[Yoann Rodiere]

Following Steve's comments, I made another few changes for the sake of
usability:

   - Moved the series-specific pages so that the path is more consistent
   with ORM documentation; the series-specific page for Search 5.8, for
   instance, is now http://staging.hibernate.org/search/releases/5.8/
   - Changed the list of releases in the "releases" page: renamed "Latest
   releases" to "Maintained series", and made the series version more
   prominent, on the left, while the latest release version is a bit less
   prominent, on the right. That way the list should be a bit less confusing.
   - Added links to the reference from the "Releases" page:
   http://staging.hibernate.org/search/releases/
   - Added a hero-unit at the top of the series-specific pages, with a few
   links: http://staging.hibernate.org/search/releases/5.8/


Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org

On 8 September 2017 at 16:44, Yoann Rodiere  wrote:

> Steve,
>
> If I understood correctly, the main difference between what I did and what
> you want is you don't want a "hub" pointing to different versions, you want
> to redirect to the page for the latest version, and from there allow to
> move to another version using drop-down.
> While I can understand you'd want that for ORM, I'm not sure it's such a
> good idea for projects such as Search or OGM, where the difference between
> two families is not only about features, but also (and in some cases,
> mainly) about which versions of other components it can integrate with. In
> this case, I'm not sure a drop-down would be enough to guide users to the
> correct version...
>
> As for your other concerns:
>
>- I'll try to add a links to the "documentation" page specific to each
>series, both in the main "releases" page and in each series-specific page.
>- The list of all micro/bugfix releases is already there, at the
>bottom of the page: http://staging.hibernate.org/search/releases/5.8/
>I'll see if I can add some sort of table of contents at the top to
>make it more visible.
>- The link to the full changelog is already there, though maybe it's
>not very visible.
>
>
> Yoann Rodière
> Hibernate NoORM Team
> yo...@hibernate.org
>
> On 8 September 2017 at 16:05, Steve Ebersole  wrote:
>
>> For me the real problem is that its not just Downloads/Releases that
>> should be (need to be really) treated in this manner - our documentation is
>> also family specific.
>>
>> So for ORM I had envisioned a "versions" (although "releases" works just
>> as well) component to the url scheme.  Vlad did this for documentation (see
>> the version drop down), but we have not yet tackled this for versions - too
>> many other more pressing tasks.  Also, I am not sure yet the best overall
>> structure for this - some of the project related information is not
>> version-specific (FAQ, Books, Paid Support, etc) while others are.
>>
>> To me personally, I think the "Documentation" and
>> Downloads/Versions/Releases should not be on the left nav.  Or, leave them
>> on the nav and have them implicitly direct to the
>> most-recent-prod-release-family.  But overall I had envisioned a
>> release-specific page - specific to release families (5.0, 5.1, etc) as
>> opposed to specific micro/bugfix releases (5.0.1, 5.0.2, etc).  This
>> release page would include:
>>
>>1. General description - what were the main points or developments
>>for this family?
>>2. Links to its documentation
>>3. List of all micro/bugfix releases as a sort-of simplified
>>changelog.  This part is still unclear in my head as to the best way to
>>represent this information, but ultimately each entry in this list would
>>need to include:
>>   1. announcement URL
>>   2. sysopsis of the main fixes/changes
>>   3. link to the full changelog
>>
>> For the most part, the information I listed for the micro/bugfix release
>> entries is covered in the release announcement so one option is to simply
>> link to each announcement for that family - possibly driven by the release
>> yaml files.
>>
>> This also fixes what I find to be a very confusing list of "latest"
>> releases.  I think that works much better as a single entry on the release
>> family page.
>>
>> Will what you did "work" for ORM?  Sure.  What I describe is just what I
>> personally think would be better in terms of ORM needs, but I have
>> absolutely no resources to do that atm.  So for now, whatever y'al

[hibernate-dev] [SEARCH] Code style - imports

[Yoann Rodiere]

Hello all,

I just noticed that our IDEA codestyle configuration files have specific
rules about how to organize imports, whereas the Eclipse ones don't.
The most noticeable difference: organizing imports in Eclipse puts static
imports at the top, while in IDEA they end up at the bottom. But there are
other differences.
The Hibernate ORM codebase doesn't seem affected by these inconsistencies
(probably because most people working on it use IDEA), but in Hibernate
Search we've already reached the point where half of our files follow one
convention, and the other half follows the other.

What's annoying here is not the inconsistencies themselves (I could live
with that), it's more that in the long run we'll end up with tons of
unnecessary changes in our commits, due to one person using IDEA to edit a
file last edited with Eclipse, and vice-versa.

To make the matter worse, Eclipse is not as flexible as IDEA, and we cannot
configure Eclipse to match the IDEA style exactly. In particular, we cannot
configure where the static imports must go: they will always go to the top (
https://bugs.eclipse.org/bugs/show_bug.cgi?id=304415).

I can see two ways out, each with its own drawbacks:

   - Switch to the "Eclipse" style, and create a Search-specific IDEA code
   style configuration, with static imports at the top. We won't be consistent
   with Hibernate ORM, though.
   - Switch to the "IDEA" style, and create a Search-specific Eclipse code
   style configuration, as close as the IDEA style as possible. As I said
   above, automatic import organizing in Eclipse will never follow this style
   exactly, so it's likely to make organizing imports in Eclipse quite
   painful. We could add checkstyle rules to make sure we strictly follow the
   style even in Eclipse.

WDYT?


Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [SEARCH] Code style - imports

[Yoann Rodiere]

>
> Fundamentally no IDE will ever produce exactly the same code so you
> need to learn control your primal lust for perfection and remember
> it's not relevant. Have some decency ;)


Sorry if that seemed "indecent", but I did mention that I could live with
the inconsistencies, and that what matters is their effect on our git
workflow :)

If you want to volunteer making the styles a bit more similar, I
> typically prefer static imports last.


Sure... thing is you can't do that in Eclipse, as I mentioned. I'll try to
align the rest of the rules, though.

Sergey sent a related PR but I'm not sure what to think of it as it
> changes several things:
>  - https://github.com/hibernate/hibernate-ide-codestyles/pull/3


Yes, it does more than what it advertises, and even the original idea
(putting static imports to the top) is not a good idea: ORM already has
static imports at the bottom in almost every file, so this change would
lead to many more changes than necessary in commits for the ORM project for
some time.

I would say that it would be nice to have Eclipse and Idea rules as similar
> as possible. The issue with that is that, for a while, the ORM people will
> have a lot of import changes, considering we can't make the Eclipse rules
> Idea like but we can do the opposite.


I doubt they'll ever agree with this solution. And I can't blame them.

If we don't want to bother the ORM team with that, we should split our
> rules between ORM and NoORM but it won't be very underestandable for the
> contributors (but it's not as if we had a lot of them and very few of them
> find our code styles without us mentioning them).
>

Seems to be the least disruptive solution. It's not ideal, but it should
improve the situation slightly and it wouldn't lead to more changes than
necessary in the future git commits.
@Sanne this means the imports will stay at the top, though. Ok with that?

I'll try to see if I can add non-disruptive checkstyle rules too, if I have
some time.

Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org

On 12 September 2017 at 11:31, Guillaume Smet 
wrote:

> Hi,
>
> Yes, I had a hard time reverting the import changes in my recent patches
> for ORM. I was changing only a few lines per file and had a lot of import
> noise.
>
> I would say that it would be nice to have Eclipse and Idea rules as
> similar as possible. The issue with that is that, for a while, the ORM
> people will have a lot of import changes, considering we can't make the
> Eclipse rules Idea like but we can do the opposite.
>
> If we don't want to bother the ORM team with that, we should split our
> rules between ORM and NoORM but it won't be very underestandable for the
> contributors (but it's not as if we had a lot of them and very few of them
> find our code styles without us mentioning them).
>
> --
> Guillaume
>
>
> On Tue, Sep 12, 2017 at 11:13 AM, Sanne Grinovero 
> wrote:
>
>> Fundamentally no IDE will ever produce exactly the same code so you
>> need to learn control your primal lust for perfection and remember
>> it's not relevant. Have some decency ;)
>>
>> What does actually matter is that we don't keep chaging the order as
>> it introduces conflicts on backporting, it's very annoying and time
>> consuming in the long run.
>>
>> My solution is simple: I don't generally care, BUT commits containing
>> code reformats just for the sake of making one's favourite tool happy
>> need be rejected, especially to stop the bad habit from developing
>> further, or anyone trying to impose its own favourite tool of the day
>> as it was the only blessed way.
>> It's fine if a couple of import reorg "slip in" as part as meaningful
>> changes.
>>
>> The real problem is that applying a patch shouldn't conflict on import
>> statements; ideally there should be a conflict resolution strategy
>> able to understand it better (e.g. teach Java to git tools..)
>>
>> If you want to volunteer making the styles a bit more similar, I
>> typically prefer static imports last.
>>
>> -1 for CheckStyle rules unless you can figure out a way to exclude
>> existing code from failing: we're not going to reformat half the code
>> base to satisfy aesthetics.
>>
>> Perhaps we could have separate sets of rules, some stricter to be
>> applied on new modules; their impact would be limited but even having
>> one module with strict rules would encourage people to reconfigure
>> their IDE in "the right way". This would ensure all new code will be
>> consistent with the rules.
>>
>> Sergey sent a relat

Re: [hibernate-dev] [SEARCH] Code style - imports

[Yoann Rodiere]

Well, if you don't mind me sending PRs with those imports in a different
order next time I change the file (because I don't spend time on organizing
imports manually, I just use CTRL+SHIFT+O), then yes, we can leave that
undefined.

Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org

On 12 September 2017 at 11:45, Sanne Grinovero  wrote:

> On 12 September 2017 at 10:42, Yoann Rodiere  wrote:
> >> Fundamentally no IDE will ever produce exactly the same code so you
> >> need to learn control your primal lust for perfection and remember
> >> it's not relevant. Have some decency ;)
> >
> >
> > Sorry if that seemed "indecent", but I did mention that I could live with
> > the inconsistencies, and that what matters is their effect on our git
> > workflow :)
> >
> >> If you want to volunteer making the styles a bit more similar, I
> >> typically prefer static imports last.
> >
> >
> > Sure... thing is you can't do that in Eclipse, as I mentioned. I'll try
> to
> > align the rest of the rules, though.
> >
> >> Sergey sent a related PR but I'm not sure what to think of it as it
> >> changes several things:
> >>  - https://github.com/hibernate/hibernate-ide-codestyles/pull/3
> >
> >
> > Yes, it does more than what it advertises, and even the original idea
> > (putting static imports to the top) is not a good idea: ORM already has
> > static imports at the bottom in almost every file, so this change would
> lead
> > to many more changes than necessary in commits for the ORM project for
> some
> > time.
> >
> >> I would say that it would be nice to have Eclipse and Idea rules as
> >> similar as possible. The issue with that is that, for a while, the ORM
> >> people will have a lot of import changes, considering we can't make the
> >> Eclipse rules Idea like but we can do the opposite.
> >
> >
> > I doubt they'll ever agree with this solution. And I can't blame them.
> >
> >> If we don't want to bother the ORM team with that, we should split our
> >> rules between ORM and NoORM but it won't be very underestandable for the
> >> contributors (but it's not as if we had a lot of them and very few of
> them
> >> find our code styles without us mentioning them).
> >
> >
> > Seems to be the least disruptive solution. It's not ideal, but it should
> > improve the situation slightly and it wouldn't lead to more changes than
> > necessary in the future git commits.
> > @Sanne this means the imports will stay at the top, though. Ok with that?
>
> Yes I'm "ok" with that. But wouldn't it be even better to leave this
> level of detail undefined?
>
> At least it would allow me to make new code having them on the bottom
> as I like them more, and you'd save some itme :)
>
> >
> > I'll try to see if I can add non-disruptive checkstyle rules too, if I
> have
> > some time.
> >
> > Yoann Rodière
> > Hibernate NoORM Team
> > yo...@hibernate.org
> >
> > On 12 September 2017 at 11:31, Guillaume Smet 
> > wrote:
> >>
> >> Hi,
> >>
> >> Yes, I had a hard time reverting the import changes in my recent patches
> >> for ORM. I was changing only a few lines per file and had a lot of
> import
> >> noise.
> >>
> >> I would say that it would be nice to have Eclipse and Idea rules as
> >> similar as possible. The issue with that is that, for a while, the ORM
> >> people will have a lot of import changes, considering we can't make the
> >> Eclipse rules Idea like but we can do the opposite.
> >>
> >> If we don't want to bother the ORM team with that, we should split our
> >> rules between ORM and NoORM but it won't be very underestandable for the
> >> contributors (but it's not as if we had a lot of them and very few of
> them
> >> find our code styles without us mentioning them).
> >>
> >> --
> >> Guillaume
> >>
> >>
> >> On Tue, Sep 12, 2017 at 11:13 AM, Sanne Grinovero 
> >> wrote:
> >>>
> >>> Fundamentally no IDE will ever produce exactly the same code so you
> >>> need to learn control your primal lust for perfection and remember
> >>> it's not relevant. Have some decency ;)
> >>>
> >>> What does actually matter is that we don't keep chaging the order as
> >>> it introduces conflicts on backporting, it

Re: [hibernate-dev] [Search and more] What is new in a give release

[Yoann Rodiere]

>
> - Releases speaks less than downloads, Where do I download Hibernate X
>  is a question we want addressed from the top level menus
>

Always amazed that there's still people out there actually downloading JARs
manually. But yes, we shouldn't forget about them.

My problem with "downloads" is that, while it conveys the correct meaning
for the minority (I hope) of users not using Maven/Gradle, it's really not
appropriate as an entry point to pages giving information about
series/releases.
Let's put it that way:

   - To a user looking for info about a particular release (maven GAV,
   changelog, ...) , a "download" entry isn't even remotely relevant
   - To a user looking to download packages, a "releases" entry does seem a
   bit relevant

But if you really want a "download" entry in the menu... would it be okay
if it just redirected to the "releases" page? I'll do that for now.

- if you do downloads -> releases, you need to also write some redirect
>  rules not to break URLs
>

I already did. Redirects don't seem to work locally for some reason,
though. They work on staging.


> - I don't like the term maintained much, I think latest like you
>  proposed makes it more neutral. You could even just name them Series
>

Steve found "latest releases" "confusing" (if I understood correctly). I
changed it to "Series" as you suggested.


> - The migration guide should probably be referenced from each individual
>  series page.
>

Done.


> - the matrix does not scale very well to that many versions.
>

Could you be more specific? Is it that you're having trouble finding out
which cell relates to which HSearch version, or which cell relates to which
dependency, or about the size of columns not being the same, or... ? I'd
rather know exactly what's wrong before trying to mess with the CSS,
because solutions to each of these problems will probably require to use
more horizontal space, and as you can see we don't have that much available.


> - in the dedicated series page, "Reference" is confusing, I'd probably
>  replace it with documentation or main documentation


Done.

Since there seems to be a general agreement that it's not worse than it
used to be, I'll send a PR soon. We can continue the discussion there.



Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org

On 11 September 2017 at 15:54, Emmanuel Bernard 
wrote:

> Hey Yoann and all,
>
> Thanks Yoann for stepping up. This is definitely much better.
> Here are non ordered comments:
>
> - Releases speaks less than downloads, Where do I download Hibernate X
>  is a question we want addressed from the top level menus
> - if you do downloads -> releases, you need to also write some redirect
>  rules not to break URLs
> - I don't like the term maintained much, I think latest like you
>  proposed makes it more neutral. You could even just name them Series
> - The migration guide should probably be referenced from each individual
>  series page.
> - the matrix does not scale very well to that many versions.
> - in the dedicated series page, "Reference" is confusing, I'd probably
>  replace it with documentation or main documentation
>
> Emmanuel
>
> On Fri 17-09-08 14:53, Yoann Rodiere wrote:
>
>> Hey,
>>
>> I pushed an update to staging. I only converted the "Search" part for now.
>> What changes:
>>
>>   - The _data folder structured changed a bit, so that we can introduces a
>>   YAML file for each series (5.5, 5.6, 5.6, 5.8, ...), containing a
>> summary
>>   of this series and a list of integration constraints (ORM > 5.2, etc.)
>>   - The "Downloads" page is renamed to "Releases", since, well, it's about
>>   more than just downloads. See
>>   http://staging.hibernate.org/search/releases/
>>   - The "Releases" page now includes a "Compatibilty matrix" section based
>>   on the new data I mentioned above
>>   - The "Releases" page now includes links to one page for each series
>>   ("More on the 5.8 series")
>>   - There is now one page for each series (see
>>   http://staging.hibernate.org/search/releases/series/5.8/). This page
>>   includes:
>>  - A short (one-line) summary of this series
>>  - A reminder of the integration constraints for this series
>>  - A section about the main changes in this release. I only wrote
>>  something for the 5.8 series for now, and I basically
>> copy/pasted sections
>>  from various blog posts.
>>  - A list of all releases in this series.
>>
>> What 

Re: [hibernate-dev] [Search and more] What is new in a give release

[Yoann Rodiere]

>
> It's more the number of columns, what if you add more version, should I
> scroll horizontally? Also releeases tend to be shown vertically with
> version in desc order. This model breaks a bit this habit.


At least versions are in desc order :D
More seriously, I was more worried about the number of dependencies than
about the number of series. We don't want to maintain a hundred branches,
so we'll probably try to keep the number of series to a minimum, but we do
want to offer as much as possible to users, so we may offer many different
integrations, and thus many different dependencies. Just think if the ORM
team wants to display supported versions of each DBMS... So I thought
showing versions horizontally would be more future-proof.
I'll try to add horizontal scrolling to the table. The oldest releases may
not be displayed, but then those are not the one we want to advertise,
so... And in any case, we have limited horizontal space, so we have to hide
*something*.
About phones, I think bootstrap has something, I'll give it a try.

On "Downloads" we only want to promote the active branches; have some
> basic series descriptions but way more ecclectic than the releases
> descriptions. We make them cross-linked and everyone is happy?


Sure, we can do that. But the "downloads" page will essentially be a
stripped-down version of the "releases" page.


Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org

On 13 September 2017 at 11:48, Sanne Grinovero  wrote:

> On 13 September 2017 at 10:41, Emmanuel Bernard 
> wrote:
> > On Tue 17-09-12 13:50, Yoann Rodiere wrote:
> >>>
> >>>
> >>> - Releases speaks less than downloads, Where do I download Hibernate X
> >>>  is a question we want addressed from the top level menus
> >>>
> >>
> >> Always amazed that there's still people out there actually downloading
> >> JARs
> >> manually. But yes, we shouldn't forget about them.
> >>
> >> My problem with "downloads" is that, while it conveys the correct
> meaning
> >> for the minority (I hope) of users not using Maven/Gradle, it's really
> not
> >> appropriate as an entry point to pages giving information about
> >> series/releases.
> >> Let's put it that way:
> >>
> >>   - To a user looking for info about a particular release (maven GAV,
> >>   changelog, ...) , a "download" entry isn't even remotely relevant
> >>   - To a user looking to download packages, a "releases" entry does
> seem a
> >>   bit relevant
> >
> >
> > You are right on principle. But if you look around, pretty much all
> > software websites have a download button leading to a page where you can
> > find releases, changelog etc. People are trained.
> >
> > http://kafka.apache.org/downloads
> > http://struts.apache.org/download.cgi#struts2513
> > http://vertx.io/download/
> >
> >
> > Spring is the exception but they have one big page for everything per
> > project. Not what we want.
> > And GitHub which has Releases https://github.com/google/guava
> >
> > I'm still not recovered from GitHub's move from Downloads to Releases to
> > be honest.
> >
> > If everyone thinks Releases is clearer and more intuitive, I won't
> > block.
>
>  - having a "Downloads" link is essential
>  - having a "Releases" page is what we think is more useful, for many
> good reasons
>
> Yet we agree they are slightly different in nature. Could we ride the
> differences and generate them both?
>
> Especially "Releases" could be a good home for all older releases and
> the "Past Roadmaps" which Emmanuel suggested before we should have,
> yet I said they don't belong on "Roadmap".
> On "Downloads" we only want to promote the active branches; have some
> basic series descriptions but way more ecclectic than the releases
> descriptions. We make them cross-linked and everyone is happy?
>
> Thanks,
> Sanne
>
>
> >
> >>
> >> But if you really want a "download" entry in the menu... would it be
> okay
> >> if it just redirected to the "releases" page? I'll do that for now.
> >>
> >> - if you do downloads -> releases, you need to also write some redirect
> >>>
> >>>  rules not to break URLs
> >>>
> >>
> >> I already did. Redirects don't seem to work locally for some reason,
> >> though. They work on staging.
> >>
> >>
> >>

Re: [hibernate-dev] [Search and more] What is new in a give release

[Yoann Rodiere]

I polished the changes, applied them to all projects (ORM, OGM, Validator,
Search), and sent a PR: https://github.com/hibernate/hibernate.org/pull/126
Could you guys review it? Mainly I'd need one person per project to check
they agree with the changes, especially in their project's section.
Also, there's still a bit of work to do for each project, mainly filling in
missing metadata (see the PR).

Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org

On 14 September 2017 at 10:38, Emmanuel Bernard 
wrote:

> On Wed 17-09-13 10:55, Sanne Grinovero wrote:
>
>> On 13 September 2017 at 10:51, Yoann Rodiere  wrote:
>>
>>> It's more the number of columns, what if you add more version, should I
>>>> scroll horizontally? Also releeases tend to be shown vertically with
>>>> version in desc order. This model breaks a bit this habit.
>>>>
>>>
>>>
>>> At least versions are in desc order :D
>>> More seriously, I was more worried about the number of dependencies than
>>> about the number of series. We don't want to maintain a hundred
>>> branches, so
>>> we'll probably try to keep the number of series to a minimum, but we do
>>> want
>>> to offer as much as possible to users, so we may offer many different
>>> integrations, and thus many different dependencies. Just think if the ORM
>>> team wants to display supported versions of each DBMS... So I thought
>>> showing versions horizontally would be more future-proof.
>>> I'll try to add horizontal scrolling to the table. The oldest releases
>>> may
>>> not be displayed, but then those are not the one we want to advertise,
>>> so...
>>> And in any case, we have limited horizontal space, so we have to hide
>>> *something*.
>>> About phones, I think bootstrap has something, I'll give it a try.
>>>
>>> On "Downloads" we only want to promote the active branches; have some
>>>> basic series descriptions but way more ecclectic than the releases
>>>> descriptions. We make them cross-linked and everyone is happy?
>>>>
>>>
>>>
>>> Sure, we can do that. But the "downloads" page will essentially be a
>>> stripped-down version of the "releases" page.
>>>
>>
>> +1 since maintenance is automated I see no problem with a little
>> redundancy.
>>
>
> I'm not sure two pages is really solving the problem. It looks like you
> don't want to make a choice. But I don't have a pro/con opinion.
> My real concern is since you will have two pages, what's the navigation
> logic? How do you reach each on of these pages?
>
> Just thinking out loud here but I think the one way to solve long
> standing Steve objective is indeed to have per series sections of the
> website (including download, documentation, migration guide)
> And a top nav for "latest/promoted" releases (like we have today
> really).
> How do you merge the two navigation wise is what I don't know.
> This is for later work anyways.
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate Search 5.8.0.Final released

[Yoann Rodiere]

Hello everyone,

We just released Hibernate Search 5.8.0.Final. Hibernate Search now
integrates with all version of Elasticsearch from 2.0 to 5.6!

Check out our blog for more information about this release:

http://in.relation.to/2017/09/14/hibernate-search-5-8-0-Final/

Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [Search and more] What is new in a give release

[Yoann Rodiere]

So, following the comments and a discussion on Hangouts on Friday, I worked
a bit more, and I just pushed what will hopefully be the last version ;)

Main changes:

   - The "Releases" menu entry now has one sub-entry for each series
   - The big, green/yellow buttons related to the stable/development
   releases, and located on the top of the "About" page and "Releases" page.
   Previously they allowed to download a ZIP, but that's arguably not very
   useful without all the information provided by the series page
   (documentation, "What's new", compatibility, ...).
   So now, they redirect to the dedicated page of the current
   stable/development series.
   See for example http://staging.hibernate.org/ogm/
   - The list of series in the "Releases" page has been modified to better
   suit its new purpose: it's just a hub to the dedicated page of each series,
   and as such its content should be very clear and provide obvious links to
   the page for each series. I made do with what's available in our current
   CSS framework (it's Bootstrap 2, which is very old), but I have good hope
   that we could improve on that one day (if we upgrade to Bootstrap 3/4).
   See for example http://staging.hibernate.org/ogm/releases/
   - The maven coordinates and download link for the latest releases has
   moved to the series-specific page. It is configurable for each project: one
   can specify in the series.yml file which artifacts should be displayed, and
   add a summary for each artifact.
   I decided against the XML format and simply displayed the GAV as
   groupId:artifactId:version. Two reasons:
1. The XML format is really, really verbose, and the pages are long
   enough as they are (one already needs to scroll one screen down to see the
   "What's new" section).
2. I can't create a single syntax-highlighted block from the content of
   YAML files (if I switch to the AsciiDoc format, I don't have access to the
   loop features of HAML, and if I stick to HAML I don't have access to
   AsciiDoc syntax highlighting).
   Yes, we could probably solve 2, given enough time. And yes, I suppose we
   could find better UI alternatives using tabs or whatever. But I've already
   spent way too much time on this. Could we just agree it's good enough and
   work on this later?
   See for example http://staging.hibernate.org/search/releases/5.8/#get_it
   - As requested, I updated the "survival guide": http://staging.
   hibernate.org/survival-guide/


Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org

On 18 September 2017 at 10:44, Sanne Grinovero  wrote:

> On 14 September 2017 at 13:34, Steve Ebersole  wrote:
> > Yoann,
> >
> > First thanks for the work on this.  I think it looks worlds better.  A
> few
> > minor things:
> >
> > Not sure of the source for this, but can we fix these doc link for 5.2
> from
> > `https://docs.jboss.org/hibernate/stable/orm/userguide/html_single/
> Hibernate_User_Guide.html`
> > to `https://docs.jboss.org/hibernate/orm/5.2`?  Also, why https?  Not
> sure
> > it matters, just found it odd
>
> Specifically about the `https` question: there's no longer any reason
> standing to avoid https, other than it being slightly more work to
> setup - in this case it's done by the jboss.org team so we can take
> advantage from it at no extra effort.
>
> There are several benefits in using it from the SEO perspective though
> so we should use and encourage it whenever possible, to make these
> URLs the canonical ones for the documentation. (and also because
> otherwise bots (and people) need to be thaught that this content is
> now available over https as well).
>
> Ideally we should set it up for our websites too.
>
> Thanks,
> Sanne
>
> > Much of the information on that ORM releases page is, in turn,
> > version/series specific.  Any reason why those pieces of information are
> not
> > part of the series?  Either in the synopsis on the releases page or on
> the
> > specific series page, or both.  Specifically
> >
> > "Compatibility Matrix" - the fact that its a table based on series is a
> good
> > indicator it is all series specific ;)
> > "Maven Repository" - I'd personally prefer to have this as part of the
> > series info
> >
> > I think the individual series pages are missing a key piece of
> > information... the "synopsis" of that series.  I guess partially this
> fits
> > under "what's new"
> >
> > Other than these minor things I love it.  Great job!
> >
> > P.S. another question is whether (and if so, how) to apply the same
> > treatment to the Documentation info 

Re: [hibernate-dev] [Search and more] What is new in a give release

[Yoann Rodiere]

No answer? So I guess I can merge it whenever I want? :-)

Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org

On 19 September 2017 at 08:36, Yoann Rodiere  wrote:

> So, following the comments and a discussion on Hangouts on Friday, I
> worked a bit more, and I just pushed what will hopefully be the last
> version ;)
>
> Main changes:
>
>- The "Releases" menu entry now has one sub-entry for each series
>- The big, green/yellow buttons related to the stable/development
>releases, and located on the top of the "About" page and "Releases" page.
>Previously they allowed to download a ZIP, but that's arguably not
>very useful without all the information provided by the series page
>(documentation, "What's new", compatibility, ...).
>So now, they redirect to the dedicated page of the current
>stable/development series.
>See for example http://staging.hibernate.org/ogm/
>- The list of series in the "Releases" page has been modified to
>better suit its new purpose: it's just a hub to the dedicated page of each
>series, and as such its content should be very clear and provide obvious
>links to the page for each series. I made do with what's available in our
>current CSS framework (it's Bootstrap 2, which is very old), but I have
>good hope that we could improve on that one day (if we upgrade to Bootstrap
>3/4).
>See for example http://staging.hibernate.org/ogm/releases/
>- The maven coordinates and download link for the latest releases has
>moved to the series-specific page. It is configurable for each project: one
>can specify in the series.yml file which artifacts should be displayed, and
>add a summary for each artifact.
>I decided against the XML format and simply displayed the GAV as
>groupId:artifactId:version. Two reasons:
> 1. The XML format is really, really verbose, and the pages are long
>enough as they are (one already needs to scroll one screen down to see the
>"What's new" section).
> 2. I can't create a single syntax-highlighted block from the content
>of YAML files (if I switch to the AsciiDoc format, I don't have access to
>the loop features of HAML, and if I stick to HAML I don't have access to
>AsciiDoc syntax highlighting).
>Yes, we could probably solve 2, given enough time. And yes, I suppose
>we could find better UI alternatives using tabs or whatever. But I've
>already spent way too much time on this. Could we just agree it's good
>enough and work on this later?
>See for example http://staging.hibernate.org/search/releases/5.8/#
>get_it
>- As requested, I updated the "survival guide": http://staging.hiberna
>te.org/survival-guide/
>
>
> Yoann Rodière
> Hibernate NoORM Team
> yo...@hibernate.org
>
> On 18 September 2017 at 10:44, Sanne Grinovero 
> wrote:
>
>> On 14 September 2017 at 13:34, Steve Ebersole 
>> wrote:
>> > Yoann,
>> >
>> > First thanks for the work on this.  I think it looks worlds better.  A
>> few
>> > minor things:
>> >
>> > Not sure of the source for this, but can we fix these doc link for 5.2
>> from
>> > `https://docs.jboss.org/hibernate/stable/orm/userguide/html_
>> single/Hibernate_User_Guide.html`
>> <https://docs.jboss.org/hibernate/stable/orm/userguide/html_single/Hibernate_User_Guide.html>
>> > to `https://docs.jboss.org/hibernate/orm/5.2`
>> <https://docs.jboss.org/hibernate/orm/5.2>?  Also, why https?  Not sure
>> > it matters, just found it odd
>>
>> Specifically about the `https` question: there's no longer any reason
>> standing to avoid https, other than it being slightly more work to
>> setup - in this case it's done by the jboss.org team so we can take
>> advantage from it at no extra effort.
>>
>> There are several benefits in using it from the SEO perspective though
>> so we should use and encourage it whenever possible, to make these
>> URLs the canonical ones for the documentation. (and also because
>> otherwise bots (and people) need to be thaught that this content is
>> now available over https as well).
>>
>> Ideally we should set it up for our websites too.
>>
>> Thanks,
>> Sanne
>>
>> > Much of the information on that ORM releases page is, in turn,
>> > version/series specific.  Any reason why those pieces of information
>> are not
>> > part of the series?  Either in the synopsis on the releases page or on
>> the
>> > specific

Re: [hibernate-dev] [Search and more] What is new in a give release

[Yoann Rodiere]

Ok, this will never end... It was good to merge less than 24h ago and now
you're arguing against the very point of this work: provide users with more
information regarding each series, so that they know what's new. (see the
first email by Emmanuel)

Please make concrete, exhaustive proposals. From what I understand, your
concerns could be addressed with only simple changes to the menu (hide
older series, add an "archived series" entry), but I don't know what to
think anymore.


Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org

On 22 September 2017 at 16:49, Sanne Grinovero  wrote:

> After some chats and a night of sleep on this, I think we need to stop
> obsessing about guiding people into the choice among multiple minor
> versions: it's hard enough that they have to pick a project.
>
> We need to encourage people to use the latest versions and we need to
> send a clear, strong message about this, no middle ground fiddling
> with names and definitions
>
> We can give them a choice between using the latest stable vs the
> latest development, but beyond this we're giving too much choice.
>
> Yet I do believe we should make it "not-hard" for people looking for
> details of other recent versions; could we consider them all
> "archived" ? Some drop downs on key areas like the ones in ORM today
> would still be welcome to make it easy to find - but let's remove the
> version choice from the "primary navigation path".
>
> There are some exceptional cases coming to mind which would need some
> mitigation; for example the fact that OGM won't work with the latest
> Search and ORM releases!
> But there are better solutions than to pollute the website experience
> by making the matching versions too visible, for example bundle it
> with OGM, link to the right versions from the OGM pages, or have the
> modules eventually pull-in the required dependencies, etc...
> (technical details irrelevant in this context).
>
> Thanks,
> Sanne
>
>
>
>
> On 22 September 2017 at 12:21, Guillaume Smet 
> wrote:
> > On Thu, Sep 21, 2017 at 6:45 PM, Sanne Grinovero 
> > wrote:
> >>
> >> *IF* you are willing to improve a minor point: I didn't expect the
> >> "Releases" menu to be expanded when not being in any of these
> >> sections.
> >
> >
> > Let's keep that one for another time.
> >
> >>
> >> Related: I wouldn't highlight both the current release and the
> >> "Releases" label, the shading looks odd and misaligned.
> >
> >
> > Yoann fixed it.
> >
> > Could we push that version to production and iterate after if required?
> >
> > It's a tad better than what we have now and I don't see a reason to
> delay it
> > more.
> >
> > Emmanuel?
> >
> > --
> > Guillaume
> >
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [Search and more] What is new in a give release

[Yoann Rodiere]

Aaaand it's merged.

I tried to clean up release YAML files as much as possible for every
project, adding missing files as necessary.

You may want to add some content to each project, most notably to the
"what's new" section of each series, but also to the compatibility matrix
of each series. I updated the survival guide with some information about
the YAML files, and I'm available if you need help.

Thanks for the feedback!


Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org

On 22 September 2017 at 23:59, Sanne Grinovero  wrote:

> Sorry for the confusion, my comment was indeed orthogonal and actually
> meant to get us all somwhat on the same page, as I have the feeling we
> have been proposing conflicting design changes (both here and in chat)
> because there is no agreement on the intent. I took that as a sign
> that our strategy needed to get some quorum first, but it was meant to
> bring closure on this change to go live asap, and possibly reduce
> debate on future proposals.
> As a suggestion maybe next time we start with the intent.
>
> I had already given my blessing to merge this and haven't changed my
> mind (I'd say so explicitly!). This is great progress and I'm eager to
> see it merged.
>
> > Yoann didn't change anything about which versions are advertised.
>
> He did. What you're probably missing is that my comment was
> championing it: the main Search landing page highlights the link to
> the latest series (and description) rather than to a pointless
> sourceforce download. (Steve understood it)
>
> Also I'm essentially conceding you're right in shutting down Search
> 5.7 (in subsequent work!) but for consistency reasons, not least
> people would wonder why there's a gap, I'd move all versions except
> latest to some form of "archived versions" or "previous series",
> whatever, exactly like Steve suggested. Which doesn't mean hard thye
> are going to be hard to find, but nudging people into the latest
> because it's the only thing we recommend rather than giving them
> various choices.
> All "series" pages need to stay for this to work nicely, which implies
> we definitely need the "series landing pages" Yoann introduced;
> un-exploding the menu of the series would help in the future when
> we'll have more - and that's why I suggested the change but it can
> wait.
>
> I don't see the conflict with Yoann's work; if any it's an important
> milestone. Frankly I'm confused how my suggestion was interpreted as a
> no-go; possibly as I didn't reply directly to your question about
> going ahead? I didn't reply on that directly because you made it clear
> you were waiting on Emmanuel's go ahead, but sorry anyway for the
> ambiguous message :) Damn mailing lists are hard!
>
> Thanks again!
> Sanne
>
>
> On 22 September 2017 at 18:45, Guillaume Smet 
> wrote:
> > Hi Sanne,
> >
> > IMHO, this is an orthogonal discussion to the problem Yoann is trying to
> > solve.
> >
> > Yoann didn't change anything about which versions are advertised.
> >
> > What I'm saying is that, if when we start a move, we have 4 other
> > discussions about 4 other things we want to change, we won't do a move
> > anymore.
> >
> > Just to show you your point will generate more discussion and is not as
> easy
> > as it seems:
> >
> > I tend to agree that we present too many versions but I think we have to
> > think carefully about what we want to do about that (you're already
> talking
> > about the OGM exceptions, but we will also have a Search exception when
> ORM
> > 6 will be released as it will require some time for us to port Search to
> 6).
> >
> > What I was saying yesterday is that I don't think keeping Search 5.7 has
> > value as people shouldn't use that version - there's no good reason for
> it.
> > I'm more torn about 5.6 as people might find it useful if they are stuck
> on
> > ORM 5.1 for whatever reason (WildFly, difficulty to upgrade...).
> >
> > So this is not an easy debate and I don't think we should block Yoann's
> work
> > for this.
> >
> > Note that It can be quite frustrating when you invested time in something
> > and you can never merge what you did because over the time we include
> other
> > subjects in the discussion. Let's be more agile about it.
> >
> > We agreed it was a good change, let's merge it and iterate from there.
> >
> > --
> > Guillaume
> >
> > On Fri, Sep 22, 2017 at 4:49 PM, Sanne Grinovero 
> > wrote:
> >>
> >> After some chats and a night of sleep on this, I think we need to stop
> >> obsessing about guiding people into the choice among multiple minor
> >> versions: it's hard enough that they have to pick a project.
> >>
> >> We need to encourage people to use the latest versions and we need to
> >> send a clear, strong message about this, no middle ground fiddling
> >> with names and definitions
> >>
> >> We can give them a choice between using the latest stable vs the
> >> latest development, but beyond this we're giving too much choice.
> >>
> >> Yet I do believe we should ma

Re: [hibernate-dev] [Search and more] What is new in a give release

[Yoann Rodiere]

>
> > As a user, I still need to be able to go to a given series page to

> understand what was done (see my initial use case). But they can be in a
> > older series section in small vs big boxes.
> This is currently missing.


NO, it is not missing. At least, the concept is there. The "What's new"
section has been here the whole time: http://staging.
hibernate.org/search/releases/5.8/#whats_new, with a big-ass "What's new"
link at the top of the series page.
So, yes, it's quite empty for now. You need to add content to the page
/yourproject/releases/yourseries/index.adoc. I added content for Search 5.8
only for now, and I'll find some time to do the same for other Search
series. And yes, there's too much content in this section for Search 5.8,
but that's mainly because there's too much content in 5.8 to begin with.
But for other projects, surely each project's leader could take a bit of
time to do that for his own project, or delegate? Some of us are even
asking to remove that "What's new" section because it's too empty... Could
we please all realize that content doesn't appear magically?

Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org

On 27 September 2017 at 22:59, Sanne Grinovero  wrote:

> On 26 September 2017 at 15:36, Emmanuel Bernard 
> wrote:
> > All I wanted initially was to be able to get a description of what each
> > series provided so that when I jump from my version to the latest, I can
> > see what's going on. Then you guys wanted to expose the matrix of
> > compatibilities as e.g. people do consume Search with a given version of
> > ORM.
> >
> > With that being said, here is what I think are the series with value to
> > users today:
> >
> > * Search: 5.8 (latest), 5.6 (ORM 5.0/5.1), maybe whatever the version in
> >  WF is
> > * Validator: 6.0 (latest), maybe whatever the version in WF is
> > * OGM: 5.2 (dev), 5.1 (stable)
> > * ORM: 5.2, 5.1, maybe the WF version if it's not 5.1
> >
> > As a user, I still need to be able to go to a given series page to
> > understand what was done (see my initial use case). But they can be in a
> > older series section in small vs big boxes.
>
> +1 that's my preference
>
> Nothing to change right now, but we'll need to evolve a bit when we'll
> want to prune the series being shown in the main area right now.
> It starts to get crowded and WF having 5.5 (rather old) I want people
> to be able to find details about it yet not "push" the version.
>
> Say we want to prune 5.7 - not being in your above list - people will
> still want to be able to find it when upgrading from 5.6 -> 5.8
>
> Thanks,
> Sanne
>
> >
> > BTW tools has a Downloads link, not Releases.
> >
> > Emmanuel
> >
> >
> > On Fri 17-09-22 17:03, Yoann Rodiere wrote:
> >>
> >> Ok, this will never end... It was good to merge less than 24h ago and
> now
> >> you're arguing against the very point of this work: provide users with
> >> more
> >> information regarding each series, so that they know what's new. (see
> the
> >> first email by Emmanuel)
> >>
> >> Please make concrete, exhaustive proposals. From what I understand, your
> >> concerns could be addressed with only simple changes to the menu (hide
> >> older series, add an "archived series" entry), but I don't know what to
> >> think anymore.
> >>
> >>
> >> Yoann Rodière
> >> Hibernate NoORM Team
> >> yo...@hibernate.org
> >>
> >> On 22 September 2017 at 16:49, Sanne Grinovero 
> >> wrote:
> >>
> >>> After some chats and a night of sleep on this, I think we need to stop
> >>> obsessing about guiding people into the choice among multiple minor
> >>> versions: it's hard enough that they have to pick a project.
> >>>
> >>> We need to encourage people to use the latest versions and we need to
> >>> send a clear, strong message about this, no middle ground fiddling
> >>> with names and definitions
> >>>
> >>> We can give them a choice between using the latest stable vs the
> >>> latest development, but beyond this we're giving too much choice.
> >>>
> >>> Yet I do believe we should make it "not-hard" for people looking for
> >>> details of other recent versions; could we consider them all
> >>> "archived" ? Some drop downs on key areas like the ones in ORM today
> >>> would still be welco

Re: [hibernate-dev] [website] Specific series page

[Yoann Rodiere]

So the order would be:

* Compatibility
* Documentation
* How to get it
* What's new
* Migrate
* Releases in this series (we just renamed it, I think it pretty much
solves the issue we were having)

Right?

Seems ok to me, no strong opinion about that. As long as compatibility info
stays at the top ;)

Anyone against it?


Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org

On 28 September 2017 at 09:42, Yoann Rodiere  wrote:

> So the order would be:
>
> * Compatibility
> * Documentation
> * How to get it
> * What's new
> * Migrate
> * Releases in this series (we just renamed it, I think it pretty much
> solves the issue we were having)
>
> Right?
>
> Seems ok to me, no strong opinion about that. As long as compatibility
> info stays at the top ;)
>
> Anyone against it?
>
>
> Yoann Rodière
> Software Engineer, Hibernate NoORM Team
> Red Hat
> yrodi...@redhat.com
>
> On 28 September 2017 at 09:20, Emmanuel Bernard 
> wrote:
>
>> And I am +1 to push the new style today. These discussions are not linked.
>>
>> > On 28 Sep 2017, at 09:17, Emmanuel Bernard 
>> wrote:
>> >
>> > Hello
>> >
>> > Watching new.hibernate.org (2017-09-28 9:00 CET), I have two minor
>> proposals.
>> >
>> > In frequency, I think people go read the docs online much more than
>> they want to know how to get it. So I would put the Documentation section
>> at the top (or below the compatibility matrix if you won’t budge).
>> >
>> > In the natural flow of information discovery (I know it breaks my
>> argument above), I would put the What’s new before the migration section.
>> >
>> > I know we have been going on and off over "Older releases”, what it is,
>> is "Previous micro releases". So how about using that title. I imagine
>> every one will understand.
>> >
>> > Emmanuel
>> > ___
>> > hibernate-dev mailing list
>> > hibernate-dev@lists.jboss.org
>> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>>
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Website - Remove the Google+ links

[Yoann Rodiere]

+1. Either we properly mirror our tweets/blog posts to G+, or we stop
advertising that account.


Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org

On 28 September 2017 at 11:51, Guillaume Smet 
wrote:

> Hi,
>
> We have a couple of Google+ links here and there on the website.
>
> I was thinking we should probably remove them as they sound a bit 2010 and
> I don't think we are actively maintaining it.
>
> WDYT?
>
> --
> Guillaume
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] [Search and more] What is new in a give release

[Yoann Rodiere]

What's in the matrix is up to each project. You can remove content by
editing the .yml file for each series, and removing elements from site.yml
under projects.orm.integrations.
I'd argue that moving away from the matrix for ORM just because Java
compatibility is "not enough" will force us to add a special case just for
ORM, and I'm not particularly interested in doing that. But feel free to do
so, or to remove the compatibility matrix completely for ORM.
I think there could be more in that matrix than just Java though, like the
compatibility with various major RDBMSs, or with some connection pools. But
again, it's your call.


Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org

On 28 September 2017 at 14:30, Steve Ebersole  wrote:

> Do y'all really think it makes sense to have JPA versions in this ORM
> "compatibility matrix"?
>
> My concern is that it is more involved (as we then try to convey in the
> section below that matrix) than a cell in a matrix/table with just a
> version number.
>
> If we end up treating JPA compatibility differently (removing from table)
> then the table is just made up of "Java compatibility", which we can
> probably illustrate simpler than a single vertical row of versions.
>
> On Thu, Sep 28, 2017 at 6:37 AM Guillaume Smet 
> wrote:
>
>> On Thu, Sep 28, 2017 at 9:21 AM, Guillaume Smet > >
>> wrote:
>>
>> > I was talking about the ability to access the old series when they are
>> not
>> > displayed in the overview.
>> >
>> > AFAICS, this is definitely missing and we would need either a page with
>> > all the series linked from the overview page or a button displaying the
>> > retired series.
>> >
>>
>> Done: I added a See older series button to the Releases / Overview page
>> and
>> to the Documentation page.
>>
>> --
>> Guillaume
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] ORM release process

[Yoann Rodiere]

Hi,

Thanks Guillaume for stepping up to explain this. I should have done it but
I guess I forgot :)


> You just need to create it for a major.
> It's this page: http://hibernate.org/orm/releases/5.2/ presenting the
> whole
> major.


I think there's a confusion between major, minor an micro here.

Our version numbers are: major.minor.micro. As far as I understood, 5 is a
major version, 5.2 is a minor version, 5.2.1 is a micro.

To sum up:

   - New micro/alpha/beta/CR/whatever: just add a new
   
_data/orm/releases//.yml
   file like you used to. No need to change/remove the previous ones, and in
   fact you shouldn't remove them: removing files will break stuff.
   - New major or minor:
  - add a new _data/orm/releases//series.yml file
  - add a new
  
_data/orm/releases//.yml
  file.
  - add a new orm/releases//index.adoc file. It can be
  empty except for the AsciiDoc metadata, but ideally you would
put in there
  a description of the minor. The content will appear in the "What's new"
  section on the series page. For example:
  http://hibernate.org/search/releases/5.8/#whats-new. Obviously you'll
  want to keep yours shorter, I'm just not good at summarizing ;)

Thanks,

Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org

On 28 September 2017 at 19:08, andrea boriero  wrote:

> Thanks a lot Guillaume and Yoann, great work.
>
> On 28 September 2017 at 17:41, Steve Ebersole  wrote:
>
> > To be honest, I think that is perfect process Guillaume.  I can now
> define
> > all that content and information in one place, which is a huge win.
> Which
> > make me think of a future nice-to-have we could consider... to drive the
> > release announcements (blog, emails, twitter, etc) from the content of a
> > series.yml.
> >
> > Thanks again for all your work on these changes.  It really does look a
> lot
> > better I think.
> >
> > On Thu, Sep 28, 2017 at 11:16 AM Chris Cranford 
> > wrote:
> >
> > > Thanks Guillaume.
> > >
> > > On 09/28/2017 10:25 AM, Guillaume Smet wrote:
> > > > Hi ORM guys,
> > > >
> > > > So with a new website comes new responsabilities.
> > > >
> > > > I updated the NoORM release process but I don't know where you put
> > these
> > > > information for ORM.
> > > >
> > > > So basically, when you release a new MAJOR version, you will have to
> > take
> > > > care of adding a *data/projects/orm/releases/series.yml *file and a
> > *orm*
> > > > */releases//index.adoc* file.
> > > >
> > > > Basically, you have to do the same thing for the release page than
> what
> > > you
> > > > already do with your custom documentation page.
> > > >
> > > > We already created them for the existing releases so you already have
> > > > templates you just have to adjust when publishing a new major
> release.
> > > >
> > >
> > > ___
> > > hibernate-dev mailing list
> > > hibernate-dev@lists.jboss.org
> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > >
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] New layout for in.relation.to

[Yoann Rodiere]

Looks great! Thanks for all the good work.

Two suggestions:

   - Add a button to display the menu on mobile
   - Do not display the author's picture on mobile, or display it on a
   separate row. I think it's currently responsible for the minimal screen
   width being relatively high, which will not look good on smaller devices.
   Note there's a "hidden-phone" class on the image, but it doesn't seem to
   work.


Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org

On 1 October 2017 at 18:43, Guillaume Smet  wrote:

> On Sun, Oct 1, 2017 at 6:18 PM, Marko Bekhta 
> wrote:
>
> > otherwise they are displayed differently for each post. WDYT?
> >
> >
> Good idea. As of now, they should be on a separate line on mobile.
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] New layout for in.relation.to

[Yoann Rodiere]

> I don't think it has much value on in.relation.to. That's why I don't
show it.

Well it's a bit confusing when coming from hibernate.org, since we made
sure to make everything look like it's the same website, and yet this
important part disappears... Granted, we could only have a stripped-down
version of the hibernate.org menu, so it would still be confusing, but
that's still better than nothing in my opinion.
On top of that, the menu button would only fill some currently unused space
on the top right, so there's really not much of a reason to remove it.

Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org

On 2 October 2017 at 11:12, Guillaume Smet  wrote:

> On Mon, Oct 2, 2017 at 9:12 AM, Yoann Rodiere  wrote:
> > Add a button to display the menu on mobile
>
> I don't think it has much value on in.relation.to. That's why I don't
> show it.
>
> > Do not display the author's picture on mobile, or display it on a
> separate row. I think it's currently responsible for the minimal screen
> width being relatively high, which will not look good on smaller devices.
> Note there's a "hidden-phone" class on the image, but it doesn't seem to
> work.
>
> I wanted to show them (the class was a leftover I didn't notice as
> these classes are not supported anymore) but you're right. I changed
> the resolution of my mobile testing the other day and I didn't notice
> it while testing in.relation.to. Better remove them.
>
> Done and pushed.
>
> --
> Guillaume
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Hibernate Search 5.8.0.Final released

[Yoann Rodiere]

Hello everyone,

We just released Hibernate Search 5.8.1.Final, with several
Elasticsearch-related fixes.

Check out our blog for more information about this release:

http://in.relation.to/2017/10/04/hibernate-search-5-8-1-Final/

Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Hibernate Search 5.8.0.Final released

[Yoann Rodiere]

As you may have understood, the subject of the previous email was wrong.
The version we just released is indeed 5.8.1.Final and not 5.8.0.Final.

Apologies for the confusion.

Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org

On 4 October 2017 at 09:31, Yoann Rodiere  wrote:

> Hello everyone,
>
> We just released Hibernate Search 5.8.1.Final, with several
> Elasticsearch-related fixes.
>
> Check out our blog for more information about this release:
>
> http://in.relation.to/2017/10/04/hibernate-search-5-8-1-Final/
>
> Yoann Rodière
> Hibernate NoORM Team
> yo...@hibernate.org
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] New layout for in.relation.to

[Yoann Rodiere]

Hush, it's a sensitive topic :) Let's just say it's on purpose, and it
could have been... harsher. The current style is already a compromise.


Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org

On 4 October 2017 at 13:22, Hardy Ferentschik  wrote:

> Hi,
>
> I like the new layout and navigation. Well done. One thing I am wondering
> though
> is the rectangular "box" around the two lines in the header? Is this
> intended?
> I find it quite harsh. I first thought it is a browser issue, but it seems
> to render the same way with any browser or device.
>
> --Hardy
>
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] Bugfix releases for Hibernate Search 5.6, 5.7 and 5.8

[Yoann Rodiere]

Hi all,

We just published three bugfix releases of Hibernate Search: 5.6.4.Final
and 5.7.3.Final and 5.8.2.Final.

Please see the blog for more details: http://in.relation.
to/2017/10/26/hibernate-search-5-6-4-and-5-7-3-and-5-8-2/

Thanks,

Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Fwd: You're on the Stride waitlist!

[Yoann Rodiere]

Steve, Robert,

The link to the room is different for guests: https://www.hipchat.
com/gRRHYZZvB
I just tested it, it works.

It also tends to be re-generated each time there's a security breach at
Atlassian, but that's another story... :)


Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org

On 27 October 2017 at 15:10, Robert Marcano 
wrote:

> On 10/26/2017 03:40 PM, Steve Ebersole wrote:
> > I can understand that.
> >
> > There is a room in our HipChat that we allow anonymous/guest access, no
> > need for an account.  The only thing you lose is the ability to see
> > history.  But I think that's a reasonable expectation.  Have you tried
> > that approach? http://hibernate.hipchat.com/chat/room/3369275
>
> I don't see any options for anonymous logins there. It redirect to a
> login page with no options for a creating a new account either.
>
> If I post an email address in order to check if it later allows to login
> anonymously or if it ask to create an account. It says:
>
> "We don't recognize that email address"
>
> >
> > On Thu, Oct 26, 2017 at 1:25 PM Robert Marcano  > > wrote:
> >
> > On 10/26/2017 12:03 PM, Steve Ebersole wrote:
> >  > Why would we?  What's the benefit over what we have?
> >  >
> >  >
> >
> > As someone that jumps from forums to forums when need to discuss bugs
> > outside bug reports systems, the lack of anonymous access to HipChat
> > discouraged me multiple times to join. Not because anonymity was
> > important, just tired of creating accounts for a few days usage in
> > another service. Just my 2 cents.
> >
> > There are other advantages but are more "political" than practical
> (OSS,
> > federated, etc).
> >
> >  >
> >  > On Thu, Oct 26, 2017 at 10:52 AM Robert Marcano
> >  > mailto:rob...@marcanoonline.com>
> > >>
> > wrote:
> >  >
> >  > On 10/26/2017 09:22 AM, Sanne Grinovero wrote:
> >  >  > Thanks, I had the same on my TODO list. Are you going to
> > convert the
> >  >  > HipChat team?
> >  >
> >  > Just out of curiosity from someone that has just 2 weeks
> > subscribed to
> >  > this mailing list. Why not try Riot/Matrix http://riot.im/ ?
> >  >
> >  >  >
> >  >  > That way we *could* all try it out, on the other hand
> since we
> >  > have no
> >  >  > choice we don't really need to evaluate it :D
> >  >  >
> >  >  > On 24 October 2017 at 19:34, Steve Ebersole
> > mailto:st...@hibernate.org>
> >  > >>
> wrote:
> >  >  >> I've signed up for a "test drive" account on Atlassian's
> > Stride
> >  > server.
> >  >  >> Stride is their replacement for HipChat.
> >  >  >>
> >  >  >> -- Forwarded message -
> >  >  >> From: Stride by Atlassian  >   > >>
> >  >  >> Date: Tue, Oct 24, 2017, 1:32 PM
> >  >  >> Subject: You're on the Stride waitlist!
> >  >  >> To: mailto:st...@hibernate.org>
> > >>
> >  >  >>
> >  >  >>
> >  >  >>
> >  >  >> [image: Stride by Atlassian]
> >  >  >>
> >  >  >> Nice! You're on the list!
> >  >  >> [image: Stride waitlist]
> >  >  >> Thanks for your interest in Stride!
> >  >  >> What is Stride?
> >  >  >> Stride is a complete communication solution that empowers
> > teams
> >  > to talk
> >  >  >> less and do more. Stride provides teams with group
> > messaging, video
> >  >  >> meetings & built-in collaboration tools. We are rolling
> > Stride
> >  > out during
> >  >  >> our Early Access Program and very excited for you and
> > your team
> >  > to try it!
> >  >  >> When will I get on Stride?
> >  >  >> When it's your turn, we'll reach out again to get your
> team
> >  > started. You'll
> >  >  >> be able to create a new team or upgrade an existing
> HipChat
> >  > team. Get
> >  >  >> answers to most of your questions on our FAQs
> >  >  >>
> >  >
> >    Stride+documentation?&utm_source=prefinery&utm_medium=
> email&utm_campaign=waitlist-confirmation>
> >  >  >> .
> >  >  >> Thanks for your support! We can't wait to see your team
> > hit its
> >  > stride.
> >  >  >> Cheers,
> >  >  >> The Stride Team
> >  >  >>
> >  >  >> Copyright 2017 Atlassian Pty Ltd. All rights reserved. We
> are
> >  > located at 341
> >  >  >> George Street, Sydney, NSW, 2000, Aus

Re: [hibernate-dev] Fwd: You're on the Stride waitlist!

[Yoann Rodiere]

> @Yoann, could you adjust the info on http://hibernate.org/community/ to
the room link you provided?

Steve already did.

Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org

On 27 October 2017 at 16:14, Gunnar Morling  wrote:

> Poor guest accessibility is the biggest issue I see about HipChat. I hope
> that's a thing improved in Stride.
>
> @Yoann, could you adjust the info on http://hibernate.org/community/ to
> the room link you provided?
>
> 2017-10-27 15:41 GMT+02:00 Yoann Rodiere :
>
>> Steve, Robert,
>>
>> The link to the room is different for guests: https://www.hipchat.
>> com/gRRHYZZvB
>> I just tested it, it works.
>>
>> It also tends to be re-generated each time there's a security breach at
>> Atlassian, but that's another story... :)
>>
>>
>> Yoann Rodière
>> Hibernate NoORM Team
>> yo...@hibernate.org
>>
>> On 27 October 2017 at 15:10, Robert Marcano 
>> wrote:
>>
>> > On 10/26/2017 03:40 PM, Steve Ebersole wrote:
>> > > I can understand that.
>> > >
>> > > There is a room in our HipChat that we allow anonymous/guest access,
>> no
>> > > need for an account.  The only thing you lose is the ability to see
>> > > history.  But I think that's a reasonable expectation.  Have you tried
>> > > that approach? http://hibernate.hipchat.com/chat/room/3369275
>> >
>> > I don't see any options for anonymous logins there. It redirect to a
>> > login page with no options for a creating a new account either.
>> >
>> > If I post an email address in order to check if it later allows to login
>> > anonymously or if it ask to create an account. It says:
>> >
>> > "We don't recognize that email address"
>> >
>> > >
>> > > On Thu, Oct 26, 2017 at 1:25 PM Robert Marcano <
>> rob...@marcanoonline.com
>> > > <mailto:rob...@marcanoonline.com>> wrote:
>> > >
>> > > On 10/26/2017 12:03 PM, Steve Ebersole wrote:
>> > >  > Why would we?  What's the benefit over what we have?
>> > >  >
>> > >  >
>> > >
>> > > As someone that jumps from forums to forums when need to discuss
>> bugs
>> > > outside bug reports systems, the lack of anonymous access to
>> HipChat
>> > > discouraged me multiple times to join. Not because anonymity was
>> > > important, just tired of creating accounts for a few days usage in
>> > > another service. Just my 2 cents.
>> > >
>> > > There are other advantages but are more "political" than practical
>> > (OSS,
>> > > federated, etc).
>> > >
>> > >  >
>> > >  > On Thu, Oct 26, 2017 at 10:52 AM Robert Marcano
>> > >  > mailto:rob...@marcanoonline.com>
>> > > <mailto:rob...@marcanoonline.com <mailto:rob...@marcanoonline.com
>> >>>
>> > > wrote:
>> > >  >
>> > >  > On 10/26/2017 09:22 AM, Sanne Grinovero wrote:
>> > >  >  > Thanks, I had the same on my TODO list. Are you going to
>> > > convert the
>> > >  >  > HipChat team?
>> > >  >
>> > >  > Just out of curiosity from someone that has just 2 weeks
>> > > subscribed to
>> > >  > this mailing list. Why not try Riot/Matrix http://riot.im/
>> ?
>> > >  >
>> > >  >  >
>> > >  >  > That way we *could* all try it out, on the other hand
>> > since we
>> > >  > have no
>> > >  >  > choice we don't really need to evaluate it :D
>> > >  >  >
>> > >  >  > On 24 October 2017 at 19:34, Steve Ebersole
>> > > mailto:st...@hibernate.org>
>> > >  > <mailto:st...@hibernate.org <mailto:st...@hibernate.org>>>
>> > wrote:
>> > >  >  >> I've signed up for a "test drive" account on
>> Atlassian's
>> > > Stride
>> > >  > server.
>> > >  >  >> Stride is their replacement for HipChat.
>> > >  >  >>
>> > >  >  >> -- Forwarded message -
>> > >  >  >> Fr

Re: [hibernate-dev] [Search] Providing an alias for the indexed type

[Yoann Rodiere]

Indeed it would make sense to allow custom type names, in particular in ES
5 and below.

In Elasticsearch 6, you can only have one type per index. The main impact
is that we will have to choose between two solutions:

   1. Either we continue as before (multiple types per index), but we
   somehow merge multiple Java types into one Elasticsearch type (we merge the
   mappings together), and we add a Hibernate Search specific field to
   distinguish between types.
   2. Or we go the Elasticsearch way and just create one index per Java type

If we go solution 2, then customizing the type name may not be necessary:
we could probably use the index name as a type name. But custom type names
wouldn't hurt.

> I probably wouldn't introduce a new annotation now, unless it matches
our intent in 6.

+1 let's wait for 6, and in particular let's wait until we support ES6... I
wouldn't want to add annotations just to drop them on the next release.


Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org

On 7 November 2017 at 22:43, Sanne Grinovero  wrote:

> +1 we should allow to override this.
>
> I think it's material for 6.x , as it ties in with the plans for
> decoupling the "index schema definition" from the "indexed type", but
> we could introduce a configuration property already in the current
> master - something like a type alias.
>
> I probably wouldn't introduce a new annotation now, unless it matches
> our intent in 6.
>
>
> On 7 November 2017 at 16:13, Guillaume Smet 
> wrote:
> > Hi,
> >
> > We just had a couple of very similar questions on SO:
> > https://stackoverflow.com/questions/47107499/override-
> elasticsearch-type-in-hibernate-search/47160930
> > https://stackoverflow.com/questions/47160030/how-to-
> configure-type-name-or-filter-by-type-query-with-elasticsearch-integratio
> >
> > The first use case makes more sense than the second one but I'm wondering
> > if we should consider adding some sort of alias to @Indexed to override
> the
> > type we use to identify the type of an object.
> >
> > WDYT?
> >
> > --
> > Guillaume
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] JPA Compliance

[Yoann Rodiere]

> I think we should just change the behavior of calling EMF#close on a closed
EMF.
> Any application that happens to be relying on us no-op'ing
> this call can easily change that to protect the call with an `#isOpen`
check.

Mentioning this just in case: the javadoc for the AutoCloseable interface
recommends making implementations of #close idempotent (not throwing
exceptions when called twice). Since Session extends AutoCloseable, and
IIRC there was a ticket about making EntityManager also extend
AutoCloseable, I thought this would be relevant.
I personally think that such a behavior is nice as it makes resource
management a little bit simpler, but in any case the interface does not
mandate it: it's just a recommendation. So you sure can do what you want.

Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org

On 24 November 2017 at 18:42, Steve Ebersole  wrote:

> I should have said:
>
> Another thing I was discussing with Andrea in chat is possibly making these
> multi-valued, or having multiple values for this.  I can't imagine the FQN
> case is really all that appealing to a user.  I'm fairly certain a user
> would rather simply say "yeah, treat transactions according the JPA spec"
> as opposed to "here is a class I will provide that will tell will treat
> transactions according to the JPA spec".  ***Or have multiple settings
> following how I started with `hibernate.query.jpaql_strict_compliance`***
>
> On Fri, Nov 24, 2017 at 11:39 AM Steve Ebersole 
> wrote:
>
> > Andrea, SF is a EMF.  Unwrapping simply returns the same instance.
> >
> > Another thing I was discussing with Andrea in chat is possibly making
> > these multi-valued, or having multiple values for this.  I can't imagine
> > the FQN case is really all that appealing to a user.  I'm fairly certain
> a
> > user would rather simply say "yeah, treat transactions according the JPA
> > spec" as opposed to "here is a class I will provide that will tell will
> > treat transactions according to the JPA spec".
> >
> > We have started to identify some cases where we deviate from the spec[1],
> > such as:
> > * Strict query compliance.  As I mentioned earlier we do have such a
> > setting already for this in particular
> > * List versus Bag determination from mappings.
> > * Closed EMF (SF) handling
> > * EntityTransaction status checking - JPA says we should throw exceptions
> > whereas we just ignore the call.
> >
> > We need to decide also which of these we want to just change outright
> > versus controlling via a setting.
> >
> > * Setting
> > * Setting, or introduce a new @Bag annotation - the annotation option is
> > actually pretty appealing since often times the bag behavior is so
> > unexpected from users...
> > * I think we should just change the behavior of calling EMF#close on a
> > closed EMF.  Any application that happens to be relying on us no-op'ing
> > this call can easily change that to protect the call with an `#isOpen`
> > check.  In fact I think we should change all of these to match the JPA
> > expectations such that it is an error to call any of the following:
> #close,
> > #getCache, #getMetamodel, #getCriteriaBuilder, #getProperties,
> > #getPersistenceUnitUtil, #createEntityManager.  To me these all seem
> pretty
> > reasonable.  And in fact I think we used to handle this all properly from
> > the EMF side.  I think we just lost that behavior when we changed to have
> > our contracts extend the JPA ones since we kept the legacy Hibernate
> > behavior in SessionFactory.
> > * This one I am very undecided.  I can see very valid arguments for each.
> >
> > [1] we really ought to start keeping a list of these.  I have started
> > adding them to the migration guide.  Just as a list of things we need to
> > support configuring or switch to the JPA "way".
> >
> > On Fri, Nov 17, 2017 at 11:06 AM andrea boriero 
> > wrote:
> >
> >> I think for 5.3 it's still fine to rely on isJpaBootstrap may be
> >> documenting that a SF obtained  from unwrapping an EMF will conform to
> the
> >> JPA spec in term of exceptions.
> >>
> >> On 16 November 2017 at 21:09, Vlad Mihalcea 
> >> wrote:
> >>
> >>> When I said multiple modes, I was thinking of defining all these
> >>> situations
> >>> In some interface which declares methods like:
> >>>
> >>> boolean throwsExceptionWhenClosingAClosedEMF()
> >>>
> >>> The interface can have two implementations for Strict JPA and Native
> >>> mode.
> >>>
> >>> However, the setting could take the FQN of the interface
> implementation,
> >>> so
> >>> a user can define those compatibility methods according to their needs.
> >>>
> >>> E.g. Maybe someone wants the Strict JPA mode but with just 2
> differences;
> >>>
> >>> - don't throw exception when closing the ENG twice
> >>> - use the native Hibernate FlushMode.AUTO instead of the JPA one.
> >>>
> >>> Vlad
> >>>
> >>> On 16 Nov 2017 10:49 pm, "Steve Ebersole"  wrote:
> >>>
> >>> > There is already a similar setting, although specific to query
> >>> language:
> 

[hibernate-dev] Hibernate Search 5.9.0.Beta1 released

[Yoann Rodiere]

Hello,

We just released Hibernate Search 5.9.0.Beta1, with a new JSR 352
integration adding a mass indexing job with a resume-after-failure feature !

Check out our blog for more information about this release:

http://in.relation.to/2017/11/27/hibernate-search-5-9-0-Beta1/

Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Killing hibernate-jpa-api ?

[Yoann Rodiere]

Seems like the right thing to do. I'm just concerned about the license. Is
it identical?
Some people might be upset to get a new dependency pulled "automatically"
if it has a stricter license...

Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org

On 13 December 2017 at 13:10, Sanne Grinovero  wrote:

> Looks like the general agreement is that we will no longer need
>  - https://github.com/hibernate/hibernate-jpa-api
>
> As we're switching to the standard API distribution, finally available:
> javax.persistence:javax.persistence-api:2.2
>
> Still I expect there's going to be some confusion about this, e.g.
> Scott was asking today in chat where to find our custom API at
> versions 2.2.
>
> I'd like to deploy a relocation artifact so that people merely
> upgrading the version to 2.2 of their dependency to
> org.hibernate.javax.persistence will get an automated warning and be
> nicely redirected to the new artifact.
>
> Any objections?
>
> The one problem I can see is that in case we need to patch it we'd
> need to restore the org.hibernate.javax.persistence and it might get
> messy, but I think we can agree the chance for this need to arise
> being extremely small.
>
> Thanks,
> Sanne
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] ManagedBeanRegistry - dependency injection support

[Yoann Rodiere]

Same here, compositions don't seem to be a reasonable use case. And even if
users provide a custom bean registry, they could just implement their
specific behavior for a few specific case, then retrieve another
implementations on their own and delegate to it however they want.
Overriding the service initiator looks like a very reasonable way to do
that.

Regarding the package, "org.hibernate.resource.beans" seems more
appropriate to me, since CDI is not the only implementation we will get and
we know it. Also, if I wanted to nitpick, injection is not really something
the bean registry must provide. We could imagine a bean registry without
any support for injection, after all, just providing "monolithic beans". It
would still make sense with respect to your ManagedBeanRegistry API.


Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org

On 14 December 2017 at 08:01, Christian Beikov 
wrote:

> I don't think someone is actually going to use more than a single DI
> framework and even if they do, they will probably bridge one way or
> another between the DI frameworks to be able to access beans from one in
> the other.
>
> So I don't think we should do "compositions" since it's not a big deal
> to integrate different DIs and is also IMO an edge case. I'd prefer the
> package name `org.hibernate.resource.di` since CDI seems to be just one
> of the possible "integrations".
>
>
> Mit freundlichen Grüßen,
> 
> *Christian Beikov*
> Am 13.12.2017 um 21:04 schrieb Steve Ebersole:
> > https://hibernate.atlassian.net/browse/HHH-11259 and friends are mainly
> > about back porting the work I did on 6.0 for the ManagedBeanRegistry
> > abstraction over dependency injection containers.  We will ship support
> for
> > CDI as well as non-managed beans (things we directly instantiate).  Of
> > course we'd ideally make it easy to plug in other DI containers such as
> > Spring.  So I wanted to discuss the configuration of this support.
> >
> > The first thing to consider is whether we want to support using multiple
> DI
> > containers simultaneously.  E.g. is it conceivable that an application
> > might want to use both CDI and Spring simultaneously?  I started building
> > in support for that via a CompositeManagedBeanRegistry implementation,
> but
> > stepping back I want to gauge whether that is "reasonable" before
> > continuing down that path
> >
> > Assuming that we do want to support such "compositions" the next question
> > is how we see this being configured.  Clearly any time a CDI BeanManager
> is
> > present during bootstrap we want to enable CDI ManagedBeanRegistry
> > support.  How would users indicate additional ManagedBeanRegistry impls
> be
> > added to the CompositeManagedBeanRegistry?  I have opinions about this,
> but
> > I'd like to hear other's thoughts...
> >
> > Note that ManagedBeanRegistry is a service and is initiated
> > via org.hibernate.resource.cdi.spi.ManagedBeanRegistryInitiator.  So it
> > would be possible to completely redefine ManagedBeanRegistry support
> simply
> > by replacing that initiator.
> >
> > A minor point... notice that the package name here is
> > `org.hibernate.resource.cdi`, even though one of the goals here is to
> > support non-CDI ManagedBeanRegistry impls.  Do we want to use a different
> > package name?  Maybe `org.hibernate.resource.beans`?
> >   ``org.hibernate.resource.di`?  ``org.hibernate.resource.injection`?
> > Other suggestions?  I'm actually ok with `org.hibernate.resource.cdi` -
> imo
> > "cdi" conveys the proper intent.  But if others feel strongly it should
> be
> > something else, I am open to hearing what and why.
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] ManagedBeanRegistry - dependency injection support

[Yoann Rodiere]

Thanks. As mentioned on the commit, I'm wondering if it's such a good idea
to cache the beans... Like you seem to do here:
https://github.com/hibernate/hibernate-orm/commit/564ec55ca10c0d5d2afd73243dc0aa31759e8f5b#diff-8daedd2dae71b88377be643ed78b5c5dR33
CDI already has features to make sure that a given bean is a singleton, and
sometimes (in Search in particular) we absolutely do not want the beans to
be singletons, but rather want to instantiate them multiple times. So... is
it really necessary?

Also the current implementation doesn't seem to support actual named beans,
which would be fetched by calling "beanManager.getBeans(clazz, new
NamedQualifier(name))" where NamedQualifier would be defined as below (not
a joke, it looks like it's actually what we should do).

private static class NamedQualifier extends
javax.enterprise.util.AnnotationLiteral implements
javax.inject.Named {
private final String name;
public NamedQualifier(String name) {
this.name = name;
}
@Override
public String value() {
return name;
}
}


Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org

On 14 December 2017 at 13:52, Steve Ebersole  wrote:

> There are a lot of changes to digest here, but if anyone wanted to take a
> look at this so far...
>
> https://github.com/hibernate/hibernate-orm/commit/
> 564ec55ca10c0d5d2afd73243dc0aa31759e8f5b
>
>
> On Thu, Dec 14, 2017 at 6:47 AM Steve Ebersole 
> wrote:
>
>> Actually my fault.  Apparently renaming the package was way too
>> aggressive and renamed the artifact
>>
>> On Thu, Dec 14, 2017 at 6:40 AM Steve Ebersole 
>> wrote:
>>
>>> Ah, nm.  They change the artifact name.  Boo!
>>>
>>> On Thu, Dec 14, 2017 at 6:39 AM Steve Ebersole 
>>> wrote:
>>>
>>>> Anyone know what happened to the 2.0 CDI artifact on Maven Central?  It
>>>> was there last week, but is no longer there...
>>>>
>>>> On Thu, Dec 14, 2017 at 5:54 AM Steve Ebersole 
>>>> wrote:
>>>>
>>>>> Thanks for the replies.  So unless we hear otherwise from anyone else,
>>>>> I will plan on supporting just one DI container.
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Dec 14, 2017 at 2:54 AM Yoann Rodiere 
>>>>> wrote:
>>>>>
>>>>>> Same here, compositions don't seem to be a reasonable use case. And
>>>>>> even if
>>>>>> users provide a custom bean registry, they could just implement their
>>>>>> specific behavior for a few specific case, then retrieve another
>>>>>> implementations on their own and delegate to it however they want.
>>>>>> Overriding the service initiator looks like a very reasonable way to
>>>>>> do
>>>>>> that.
>>>>>>
>>>>>> Regarding the package, "org.hibernate.resource.beans" seems more
>>>>>> appropriate to me, since CDI is not the only implementation we will
>>>>>> get and
>>>>>> we know it. Also, if I wanted to nitpick, injection is not really
>>>>>> something
>>>>>> the bean registry must provide. We could imagine a bean registry
>>>>>> without
>>>>>> any support for injection, after all, just providing "monolithic
>>>>>> beans". It
>>>>>> would still make sense with respect to your ManagedBeanRegistry API.
>>>>>>
>>>>>>
>>>>>> Yoann Rodière
>>>>>> Hibernate NoORM Team
>>>>>> yo...@hibernate.org
>>>>>>
>>>>>> On 14 December 2017 at 08:01, Christian Beikov <
>>>>>> christian.bei...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>> > I don't think someone is actually going to use more than a single DI
>>>>>> > framework and even if they do, they will probably bridge one way or
>>>>>> > another between the DI frameworks to be able to access beans from
>>>>>> one in
>>>>>> > the other.
>>>>>> >
>>>>>> > So I don't think we should do "compositions" since it's not a big
>>>>>> deal
>>>>>> > to integrate different DIs and is also IMO an edge case. I'd prefer
>>>>>> the
>>>>>> > package name `org.hibernate.resource.di` since CDI seems to b

Re: [hibernate-dev] ManagedBeanRegistry - dependency injection support

[Yoann Rodiere]

Yeah, it was 4AM in France when you asked :) I answered later on HipChat,
the answer is basically the one I gave in my email.

Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org

On 14 December 2017 at 14:38, Steve Ebersole  wrote:

> WRT to named beans, I asked Guillaume on HipChat what that is supposed to
> look like.  IIRC he mentioned producers in Paris, but I found no
> straight-forward way to get from name+class to a bean.
>
> He may have answered, I just have not been on HipChat yet today...
>
> On Thu, Dec 14, 2017 at 7:36 AM Steve Ebersole 
> wrote:
>
>> Its easier to cleanup
>>
>> On Thu, Dec 14, 2017 at 6:52 AM Steve Ebersole 
>> wrote:
>>
>>> There are a lot of changes to digest here, but if anyone wanted to take
>>> a look at this so far...
>>>
>>> https://github.com/hibernate/hibernate-orm/commit/
>>> 564ec55ca10c0d5d2afd73243dc0aa31759e8f5b
>>>
>>>
>>> On Thu, Dec 14, 2017 at 6:47 AM Steve Ebersole 
>>> wrote:
>>>
>>>> Actually my fault.  Apparently renaming the package was way too
>>>> aggressive and renamed the artifact
>>>>
>>>> On Thu, Dec 14, 2017 at 6:40 AM Steve Ebersole 
>>>> wrote:
>>>>
>>>>> Ah, nm.  They change the artifact name.  Boo!
>>>>>
>>>>> On Thu, Dec 14, 2017 at 6:39 AM Steve Ebersole 
>>>>> wrote:
>>>>>
>>>>>> Anyone know what happened to the 2.0 CDI artifact on Maven Central?
>>>>>> It was there last week, but is no longer there...
>>>>>>
>>>>>> On Thu, Dec 14, 2017 at 5:54 AM Steve Ebersole 
>>>>>> wrote:
>>>>>>
>>>>>>> Thanks for the replies.  So unless we hear otherwise from anyone
>>>>>>> else, I will plan on supporting just one DI container.
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On Thu, Dec 14, 2017 at 2:54 AM Yoann Rodiere 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Same here, compositions don't seem to be a reasonable use case. And
>>>>>>>> even if
>>>>>>>> users provide a custom bean registry, they could just implement
>>>>>>>> their
>>>>>>>> specific behavior for a few specific case, then retrieve another
>>>>>>>> implementations on their own and delegate to it however they want.
>>>>>>>> Overriding the service initiator looks like a very reasonable way
>>>>>>>> to do
>>>>>>>> that.
>>>>>>>>
>>>>>>>> Regarding the package, "org.hibernate.resource.beans" seems more
>>>>>>>> appropriate to me, since CDI is not the only implementation we will
>>>>>>>> get and
>>>>>>>> we know it. Also, if I wanted to nitpick, injection is not really
>>>>>>>> something
>>>>>>>> the bean registry must provide. We could imagine a bean registry
>>>>>>>> without
>>>>>>>> any support for injection, after all, just providing "monolithic
>>>>>>>> beans". It
>>>>>>>> would still make sense with respect to your ManagedBeanRegistry API.
>>>>>>>>
>>>>>>>>
>>>>>>>> Yoann Rodière
>>>>>>>> Hibernate NoORM Team
>>>>>>>> yo...@hibernate.org
>>>>>>>>
>>>>>>>> On 14 December 2017 at 08:01, Christian Beikov <
>>>>>>>> christian.bei...@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> > I don't think someone is actually going to use more than a single
>>>>>>>> DI
>>>>>>>> > framework and even if they do, they will probably bridge one way
>>>>>>>> or
>>>>>>>> > another between the DI frameworks to be able to access beans from
>>>>>>>> one in
>>>>>>>> > the other.
>>>>>>>> >
>>>>>>>> > So I don't think we should do "compositions" since it's not a big
>>>>>>>> deal
>>>>>>>> > to integrate different DIs and is also I

Re: [hibernate-dev] ManagedBeanRegistry - dependency injection support

[Yoann Rodiere]

Here is how it should work from what I understand (adapted from an
implementation in Search, which has slightly different requirements):

static  T getBeanInstance(BeanManager beanManager, String beanName,
Class contract) {
Set> beans = beanManager.getBeans(contract, new NamedQualifier(
beanName));
if ( beans.isEmpty() || beans.size() > 1 ) {
// TODO proper error messages
throw new IllegalArgumentException( "No matching beans or multiple matching
beans" );
}
Bean bean = beans.iterator().next();
CreationalContext creationalContext = beanManager.createCreationalContext(
bean );
return contract.cast( beanManager.getReference( bean, contract,
creationalContext ) );
}

With NamedQualifier being the implementation I gave before.

Sure, let's talk about it later on HipChat. Especially the caching thing,
it's really a blocker for Search.

I'll be online to travel in about 3 hours, though.


Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org

On 14 December 2017 at 14:46, Steve Ebersole  wrote:

> I'll be on HipChat later after I get back from taking my son and daughter
> to school.  Maybe it is easier to discuss there.
>
> On Thu, Dec 14, 2017 at 7:44 AM Steve Ebersole 
> wrote:
>
>> But your answer above does not answer my question ;)
>>
>> I still have no idea how to go from name+Class -> bean.
>>
>>
>> On Thu, Dec 14, 2017 at 7:41 AM Yoann Rodiere 
>> wrote:
>>
>>> Yeah, it was 4AM in France when you asked :) I answered later on
>>> HipChat, the answer is basically the one I gave in my email.
>>>
>>> Yoann Rodière
>>> Hibernate NoORM Team
>>> yo...@hibernate.org
>>>
>>> On 14 December 2017 at 14:38, Steve Ebersole 
>>> wrote:
>>>
>>>> WRT to named beans, I asked Guillaume on HipChat what that is supposed
>>>> to look like.  IIRC he mentioned producers in Paris, but I found no
>>>> straight-forward way to get from name+class to a bean.
>>>>
>>>> He may have answered, I just have not been on HipChat yet today...
>>>>
>>>> On Thu, Dec 14, 2017 at 7:36 AM Steve Ebersole 
>>>> wrote:
>>>>
>>>>> Its easier to cleanup
>>>>>
>>>>> On Thu, Dec 14, 2017 at 6:52 AM Steve Ebersole 
>>>>> wrote:
>>>>>
>>>>>> There are a lot of changes to digest here, but if anyone wanted to
>>>>>> take a look at this so far...
>>>>>>
>>>>>> https://github.com/hibernate/hibernate-orm/commit/564ec55ca1
>>>>>> 0c0d5d2afd73243dc0aa31759e8f5b
>>>>>>
>>>>>>
>>>>>> On Thu, Dec 14, 2017 at 6:47 AM Steve Ebersole 
>>>>>> wrote:
>>>>>>
>>>>>>> Actually my fault.  Apparently renaming the package was way too
>>>>>>> aggressive and renamed the artifact
>>>>>>>
>>>>>>> On Thu, Dec 14, 2017 at 6:40 AM Steve Ebersole 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Ah, nm.  They change the artifact name.  Boo!
>>>>>>>>
>>>>>>>> On Thu, Dec 14, 2017 at 6:39 AM Steve Ebersole 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Anyone know what happened to the 2.0 CDI artifact on Maven
>>>>>>>>> Central?  It was there last week, but is no longer there...
>>>>>>>>>
>>>>>>>>> On Thu, Dec 14, 2017 at 5:54 AM Steve Ebersole <
>>>>>>>>> st...@hibernate.org> wrote:
>>>>>>>>>
>>>>>>>>>> Thanks for the replies.  So unless we hear otherwise from anyone
>>>>>>>>>> else, I will plan on supporting just one DI container.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On Thu, Dec 14, 2017 at 2:54 AM Yoann Rodiere <
>>>>>>>>>> yo...@hibernate.org> wrote:
>>>>>>>>>>
>>>>>>>>>>> Same here, compositions don't seem to be a reasonable use case.
>>>>>>>>>>> And even if
>>>>>>>>>>> users provide a custom bean registry, they could just implement
>>>>>>>>>>> their
>>>>>>>>>>> specific behavior for a few specific case, then retrieve another
>&g

[hibernate-dev] CDI integration in Hibernate ORM and the Application scope

[Yoann Rodiere]

Hello all,

TL;DR: Application-scoped beans cannot be used as part of the @PreDestroy
method of ORM-instantiated CDI beans, and it's a bit odd because they can
be used as part of the @PostConstruct method.

I've been testing the CDI integration in Hibernate ORM for the past few
days, trying to integrate it into Search. I think I've discovered something
odd: when CDI-managed beans are destroyed, they cannot access other
Application-scoped CDI beans anymore. Not sure whether this is a problem or
not, so maybe we should discuss it a bit before going forward with the
current behavior.

Short reminder: scopes define when CDI beans are created and destroyed.
@ApplicationScoped is pretty self-explanatory: created when the application
starts and destroyed when it stops. Some other scopes are a bit more
convoluted: @Singleton basically means created *before* the application
starts and destroyed *after* the application stops (and also means "this
bean shall not be proxied"), @Dependent means created when an instance is
requested and destroyed when the instance is released, etc.

The thing is, Hibernate ORM is typically started very early and shut down
very late in the CDI lifecycle - at least within WildFly. So when Hibernate
starts, CDI Application-scoped beans haven't been instantiated yet, and it
turns out that when Hibernate ORM shuts down, CDI has already destroyed
Application-scoped beans.

Regarding startup, Steve and Scott solved the problem by delaying bean
instantiation to some point in the future when the Application scope is
active (and thus Application-scoped beans are available). This makes it
possible to use Application-scoped beans within ORM-instantiated beans as
soon as the latter are constructed (i.e. within their @PostConstruct
methods).
However, when Hibernate ORM shuts down, the Application scope has already
been terminated. So when ORM destroys the beans it instantiated, those
ORM-instantiated beans cannot call a method on referenced
Application-scoped beans (CDI proxies will throw an exception).

All in all, the only type of beans we can currently use in a @PreDestroy
method of an ORM-instantiated bean is @Dependent beans. @Singleton beans
will work, but only because they are not proxied and thus you can cheat and
use them even after they have been destroyed... which I definitely wouldn't
recommend.

I see two ways to handle the issue:

   1. We don't change anything, and simply document somewhere that beans
   instantiated as part of the CDI integration are instantiated within the
   Application scope, but are destroyed outside of it. And we suggest that any
   bean used in @PostDestroy method in an ORM-instantiated bean (directly or
   not) must have either a @Dependent scope, or a @Singleton scope and no
   @PostDestroy method.
   2. We implement an "early shut-down" somehow, which would bring forward
   bean destruction to some time when the Application scope is still active.

#1 may be enough for now, even though the behavior feels a bit odd, and
forces users to resort to less-than-ideal practices (using a @Singleton
bean after it has been destroyed).

#2 would require changes in WildFly and may be a bit complex. In
particular, if we aren't careful, Application-scoped beans may not be able
to use Hibernate ORM from within their @PreDestroy methods... Which is
probably not a good idea. So we would have to find a solution together with
the WildFly team. Also to be considered: Hibernate Search would have to be
shut down just before the "early shut-down" of Hibernate ORM occurs,
because Hibernate Search cannot function at all without the beans it
retrieves from the CDI context.

Thoughts?


Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] CDI integration in Hibernate ORM and the Application scope

[Yoann Rodiere]

> we need to find a way to have the DI framework
> take in consideration our additional components both in terms of DI
> consumers and providers

Not sure what you mean by that. Currently the DI framework doesn't know who
uses these components, and therefore it's up to us to tell the DI framework
when they can be "destroyed".
Do you suggest that we make the DI framework aware of the Hibernate ORM =>
 dependency, and let it do what it can to handle that
dependency?

I know this would work (and probably is already doable without much change)
in Spring, because in Spring DI the EntityManagerFactory is viewed as just
another type of bean, and therefore its whole lifecycle is already handled
by Spring DI.
In WildFly though, things are a little bit different: from what I
understood, WildFly starts the persistence units (Hibernate ORM)
explicitly, and only then it starts the CDI context (Weld). And the
opposite when shutting down. The persistence units lifecycle really isn't
integrated into CDI... But maybe it should be. In particular the ability to
lazily load the persistence units when they are first requested by a CDI
bean, and to automatically close a persistence unit when no CDI bean
depends on it anymore, would solve a lot of dependency issues. Or at least
it would move the problems out of our scope.
However, I'm not sure that such behavior would be compatible with all the
specs WildFly must comply with.

Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org

On 20 December 2017 at 15:48, Sanne Grinovero  wrote:

> Any dependency injection framework will have some capability to define
> the graph of dependencies across components, and such graph could be
> very complex, with details only known to the framework.
>
> I don't think we can solve the integration by having "before all
> others" / "after all others" phases as that's too coarse grained to
> define a full graph; we need to find a way to have the DI framework
> take in consideration our additional components both in terms of DI
> consumers and providers - then let the framework wire up things in the
> order it prefers. This is also to allow the DI engine to print
> appropriate warnings for un-resolvable situations with its native
> error handling, which would resolve in more familiar error messages.
>
> If that's not doable *or a priority* then all we can do is try to make
> it clear enough that there will be limitations and hopefully describe
> these clearly. Some of such limitations might be puzzling as you
> describe.
>
>
>
> On 20 December 2017 at 12:50, Yoann Rodiere  wrote:
> > Hello all,
> >
> > TL;DR: Application-scoped beans cannot be used as part of the @PreDestroy
> > method of ORM-instantiated CDI beans, and it's a bit odd because they can
> > be used as part of the @PostConstruct method.
> >
> > I've been testing the CDI integration in Hibernate ORM for the past few
> > days, trying to integrate it into Search. I think I've discovered
> something
> > odd: when CDI-managed beans are destroyed, they cannot access other
> > Application-scoped CDI beans anymore. Not sure whether this is a problem
> or
> > not, so maybe we should discuss it a bit before going forward with the
> > current behavior.
> >
> > Short reminder: scopes define when CDI beans are created and destroyed.
> > @ApplicationScoped is pretty self-explanatory: created when the
> application
> > starts and destroyed when it stops. Some other scopes are a bit more
> > convoluted: @Singleton basically means created *before* the application
> > starts and destroyed *after* the application stops (and also means "this
> > bean shall not be proxied"), @Dependent means created when an instance is
> > requested and destroyed when the instance is released, etc.
> >
> > The thing is, Hibernate ORM is typically started very early and shut down
> > very late in the CDI lifecycle - at least within WildFly. So when
> Hibernate
> > starts, CDI Application-scoped beans haven't been instantiated yet, and
> it
> > turns out that when Hibernate ORM shuts down, CDI has already destroyed
> > Application-scoped beans.
> >
> > Regarding startup, Steve and Scott solved the problem by delaying bean
> > instantiation to some point in the future when the Application scope is
> > active (and thus Application-scoped beans are available). This makes it
> > possible to use Application-scoped beans within ORM-instantiated beans as
> > soon as the latter are constructed (i.e. within their @PostConstruct
> > methods).
> > However, when Hibernate ORM shuts down, the Application scope has already
> > been terminated. So 

Re: [hibernate-dev] ManagedBeanRegistry - dependency injection support

[Yoann Rodiere]

Hi,

Following our conversations on HipChat and the various changes you
implemented (thanks!), I tested the current implementation. There were a
few issues, but I managed to fix them and make all the tests in Hibernate
Search pass.
Here is a PR with the fixes:
https://github.com/hibernate/hibernate-orm/pull/2092

Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org

On 14 December 2017 at 18:42, Steve Ebersole  wrote:

> Here is the commit with initial support for named CDI beans and support
> for bypassing registry caching of ManagedBeans : https://github.com/
> hibernate/hibernate-orm/commit/ddc1f03abc675a27ed025b8c00495d39bca7fb60
>
> There is still a question of whether named beans support needs to do
> the javax.enterprise.inject.spi.InjectionTarget stuff
>
> Christian, I ended up going to "beans" as the package name because this
> supports non-CDI environments (direct instantiation) too.  Not overly a fan
> of "beans" (overloaded term) but it was a lesser of evils.
>
> On Thu, Dec 14, 2017 at 10:57 AM Steve Ebersole 
> wrote:
>
>> Yoann, does this approach still need to do the injections
>> (javax.enterprise.inject.spi.InjectionTarget)?
>>
>>
>> On Thu, Dec 14, 2017 at 8:01 AM Yoann Rodiere 
>> wrote:
>>
>>> Here is how it should work from what I understand (adapted from an
>>> implementation in Search, which has slightly different requirements):
>>>
>>> static  T getBeanInstance(BeanManager beanManager, String beanName,
>>> Class contract) {
>>> Set> beans = beanManager.getBeans(contract, new NamedQualifier(
>>> beanName));
>>> if ( beans.isEmpty() || beans.size() > 1 ) {
>>> // TODO proper error messages
>>> throw new IllegalArgumentException( "No matching beans or multiple
>>> matching beans" );
>>> }
>>> Bean bean = beans.iterator().next();
>>> CreationalContext creationalContext = 
>>> beanManager.createCreationalContext(
>>> bean );
>>> return contract.cast( beanManager.getReference( bean, contract,
>>> creationalContext ) );
>>> }
>>>
>>> With NamedQualifier being the implementation I gave before.
>>>
>>> Sure, let's talk about it later on HipChat. Especially the caching
>>> thing, it's really a blocker for Search.
>>>
>>> I'll be online to travel in about 3 hours, though.
>>>
>>>
>>> Yoann Rodière
>>> Hibernate NoORM Team
>>> yo...@hibernate.org
>>>
>>> On 14 December 2017 at 14:46, Steve Ebersole 
>>> wrote:
>>>
>>>> I'll be on HipChat later after I get back from taking my son and
>>>> daughter to school.  Maybe it is easier to discuss there.
>>>>
>>>> On Thu, Dec 14, 2017 at 7:44 AM Steve Ebersole 
>>>> wrote:
>>>>
>>>>> But your answer above does not answer my question ;)
>>>>>
>>>>> I still have no idea how to go from name+Class -> bean.
>>>>>
>>>>>
>>>>> On Thu, Dec 14, 2017 at 7:41 AM Yoann Rodiere 
>>>>> wrote:
>>>>>
>>>>>> Yeah, it was 4AM in France when you asked :) I answered later on
>>>>>> HipChat, the answer is basically the one I gave in my email.
>>>>>>
>>>>>> Yoann Rodière
>>>>>> Hibernate NoORM Team
>>>>>> yo...@hibernate.org
>>>>>>
>>>>>> On 14 December 2017 at 14:38, Steve Ebersole 
>>>>>> wrote:
>>>>>>
>>>>>>> WRT to named beans, I asked Guillaume on HipChat what that is
>>>>>>> supposed to look like.  IIRC he mentioned producers in Paris, but I 
>>>>>>> found
>>>>>>> no straight-forward way to get from name+class to a bean.
>>>>>>>
>>>>>>> He may have answered, I just have not been on HipChat yet today...
>>>>>>>
>>>>>>> On Thu, Dec 14, 2017 at 7:36 AM Steve Ebersole 
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Its easier to cleanup
>>>>>>>>
>>>>>>>> On Thu, Dec 14, 2017 at 6:52 AM Steve Ebersole 
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> There are a lot of changes to digest here, but if anyone wanted to
>>>>>>>>> take a look at this so far...
>>>>>>>

Re: [hibernate-dev] ManagedBeanRegistry - dependency injection support

[Yoann Rodiere]

> However, I do think that there is still a need to expand the proposal
Scott and I want to make to the CDI spec wrt something like our
ExtendedBeanManager to also account for the shutdown phase

+1, I sent an email about just that on the mailing list. There are some
drawbacks to this approach though, and Sanne suggested deeper integration
into CDI would be a more future-proof path.
The subject of this thread was "CDI integration in Hibernate ORM and the
Application scope".

Yoann Rodière
Hibernate NoORM Team
yo...@hibernate.org

On 21 December 2017 at 16:36, Steve Ebersole  wrote:

> Awesome!  Glad it worked out.
>
> However, I do think that there is still a need to expand the proposal
> Scott and I want to make to the CDI spec wrt something like our
> ExtendedBeanManager to also account for the shutdown phase.  In addition to
> knowing when the BeanManager is ready to use, it would be nice to know when
> the BeanManager is ready to shutdown (a before shutdown hook).  At that
> point we could begin cleaning up our CreationalContext, etc refs.
>
> Scott, do you already have enough insight into that in WildFly for us to
> go ahead and do that in our integration today?
>
> On Thu, Dec 21, 2017, 1:53 AM Yoann Rodiere  wrote:
>
>> Hi,
>>
>> Following our conversations on HipChat and the various changes you
>> implemented (thanks!), I tested the current implementation. There were a
>> few issues, but I managed to fix them and make all the tests in Hibernate
>> Search pass.
>> Here is a PR with the fixes: https://github.com/
>> hibernate/hibernate-orm/pull/2092
>>
>> Yoann Rodière
>> Hibernate NoORM Team
>> yo...@hibernate.org
>>
>> On 14 December 2017 at 18:42, Steve Ebersole  wrote:
>>
>>> Here is the commit with initial support for named CDI beans and support
>>> for bypassing registry caching of ManagedBeans : https://github.com/
>>> hibernate/hibernate-orm/commit/ddc1f03abc675a27ed025b8c00495d39bca7fb60
>>>
>>> There is still a question of whether named beans support needs to do
>>> the javax.enterprise.inject.spi.InjectionTarget stuff
>>>
>>> Christian, I ended up going to "beans" as the package name because this
>>> supports non-CDI environments (direct instantiation) too.  Not overly a fan
>>> of "beans" (overloaded term) but it was a lesser of evils.
>>>
>>> On Thu, Dec 14, 2017 at 10:57 AM Steve Ebersole 
>>> wrote:
>>>
>>>> Yoann, does this approach still need to do the injections
>>>> (javax.enterprise.inject.spi.InjectionTarget)?
>>>>
>>>>
>>>> On Thu, Dec 14, 2017 at 8:01 AM Yoann Rodiere 
>>>> wrote:
>>>>
>>>>> Here is how it should work from what I understand (adapted from an
>>>>> implementation in Search, which has slightly different requirements):
>>>>>
>>>>> static  T getBeanInstance(BeanManager beanManager, String beanName,
>>>>> Class contract) {
>>>>> Set> beans = beanManager.getBeans(contract, new
>>>>> NamedQualifier(beanName));
>>>>> if ( beans.isEmpty() || beans.size() > 1 ) {
>>>>> // TODO proper error messages
>>>>> throw new IllegalArgumentException( "No matching beans or multiple
>>>>> matching beans" );
>>>>> }
>>>>> Bean bean = beans.iterator().next();
>>>>> CreationalContext creationalContext = 
>>>>> beanManager.createCreationalContext(
>>>>> bean );
>>>>> return contract.cast( beanManager.getReference( bean, contract,
>>>>> creationalContext ) );
>>>>> }
>>>>>
>>>>> With NamedQualifier being the implementation I gave before.
>>>>>
>>>>> Sure, let's talk about it later on HipChat. Especially the caching
>>>>> thing, it's really a blocker for Search.
>>>>>
>>>>> I'll be online to travel in about 3 hours, though.
>>>>>
>>>>>
>>>>> Yoann Rodière
>>>>> Hibernate NoORM Team
>>>>> yo...@hibernate.org
>>>>>
>>>>> On 14 December 2017 at 14:46, Steve Ebersole 
>>>>> wrote:
>>>>>
>>>>>> I'll be on HipChat later after I get back from taking my son and
>>>>>> daughter to school.  Maybe it is easier to discuss there.
>>>>>>
>>>>>> On Thu, Dec 14, 2017 at 7:44 AM Steve Ebersole 
>>>>&