Re: [hibernate-dev] Changing or deprecating @AnalyzerDef

2016-03-03 Thread Sanne Grinovero
On 3 March 2016 at 16:46, Emmanuel Bernard wrote: > They were intended to be there. Are they useful there is another story > we can debate. > > definitions can be defined on fields or methods. I could not find the > code that would isolate the definition between different fields but I > would have

Re: [hibernate-dev] Connecting to a resource which isn't ready yet (or not ready anymore)

2016-03-03 Thread Sanne Grinovero
On 3 March 2016 at 16:53, Emmanuel Bernard wrote: > Regardless of the queue approach you want in the future, it should not > be coupled with Elasticsearch's effort. > It's an orthogonal concern on how to decouple work generation from work > consumption. > That way we can reuse the other queue syst

Re: [hibernate-dev] Changing or deprecating @AnalyzerDef

2016-03-03 Thread Emmanuel Bernard
They were intended to be there. Are they useful there is another story we can debate. definitions can be defined on fields or methods. I could not find the code that would isolate the definition between different fields but I would have expected that intent. At any rate there is an explicit handli

Re: [hibernate-dev] Connecting to a resource which isn't ready yet (or not ready anymore)

2016-03-03 Thread Emmanuel Bernard
Regardless of the queue approach you want in the future, it should not be coupled with Elasticsearch's effort. It's an orthogonal concern on how to decouple work generation from work consumption. That way we can reuse the other queue systems for Hibernate Search on Lucene with retries policies and

Re: [hibernate-dev] Connecting to a resource which isn't ready yet (or not ready anymore)

2016-03-03 Thread Sanne Grinovero
On 3 March 2016 at 15:11, Emmanuel Bernard wrote: > On Thu 2016-03-03 14:19, Sanne Grinovero wrote: >> Back to my Elasticsearch problem: I think the short term solution >> would be that we actually have to check for the index state after >> having it created, and keep checking in a loop until some

Re: [hibernate-dev] Connecting to a resource which isn't ready yet (or not ready anymore)

2016-03-03 Thread Emmanuel Bernard
On Thu 2016-03-03 14:19, Sanne Grinovero wrote: > Back to my Elasticsearch problem: I think the short term solution > would be that we actually have to check for the index state after > having it created, and keep checking in a loop until some short > timeout expires. > -> https://hibernate.atlass

[hibernate-dev] Changing or deprecating @AnalyzerDef

2016-03-03 Thread Sanne Grinovero
I just realized that the definiton for @AnalyzerDef allows many target ypes: @Target({ ElementType.PACKAGE, ElementType.TYPE, ElementType.FIELD, ElementType.METHOD }) I think FIELD and METHOD might not have been intended to be there. Should we correct this in 6 to @Target({ ElementType.PACKAGE,

Re: [hibernate-dev] Connecting to a resource which isn't ready yet (or not ready anymore)

2016-03-03 Thread Gunnar Morling
Hi, I think waiting until the index has become available after creation is fine for the time being. I'd wait and see how practical experiences look like, i.e. how long does it take in practice to create indexes with a realistic number of shards and replicas. Also we discussed creating a separate

[hibernate-dev] Connecting to a resource which isn't ready yet (or not ready anymore)

2016-03-03 Thread Sanne Grinovero
My question here was triggered by a specific case in Hibernate Search but it applies well to ORM's datasources, caches, and very much to OGM as well. When creating an index on Elasticsearch, the index is not "instantaneously" ready. The REST request creates the definition, but the response will on

Re: [hibernate-dev] Everyone: Need volunteers for mentoring GSOC

2016-03-03 Thread Gunnar Morling
Ahaha, ok. I took previous contribution as a given for active participants on hibernate-dev and people considering to mentor ;) Sorry I misread. 2016-03-03 12:38 GMT+01:00 Sanne Grinovero : > I asked for mentors, not students. > > On Thu, 3 Mar 2016 11:05 Gunnar Morling, wrote: >> >> Hi, >> >> I'

Re: [hibernate-dev] Everyone: Need volunteers for mentoring GSOC

2016-03-03 Thread Sanne Grinovero
I asked for mentors, not students. On Thu, 3 Mar 2016 11:05 Gunnar Morling, wrote: > Hi, > > I'll write up the proposal for the batch job for mass indexing and > submit it to > https://developer.jboss.org/wiki/JBossCommunityGoogleSummerOfCode2016Ideas > . > > > It would need to be someone who's

Re: [hibernate-dev] Everyone: Need volunteers for mentoring GSOC

2016-03-03 Thread Gunnar Morling
Hi, I'll write up the proposal for the batch job for mass indexing and submit it to https://developer.jboss.org/wiki/JBossCommunityGoogleSummerOfCode2016Ideas. > It would need to be someone who's regularly contributing already... Personally I don't think that's needed and also it's not in the s

Re: [hibernate-dev] HHH-8999/HHH-10413 and Comparable IDs

2016-03-03 Thread Gail Badner
Missed something. Please see below... On Wed, Mar 2, 2016 at 11:49 PM, Gail Badner wrote: > ExecutableList#add attempts to keep track of whether the Executable > objects are sorted. [1] > > Except for entity insert actions (which use InsertActionSorter), > ExecutableList#add uses the following t

Re: [hibernate-dev] [Search] Travis support

2016-03-03 Thread Mark Paluch
It’s a setting in the .travis.yml file. TravisCI creates multiple jobs (one per JDK) itself and runs the whole build using the configured JDKs. See https://docs.travis-ci.com/user/languages/java#Testing-Against-Multiple-JDKs

Re: [hibernate-dev] [Search] Travis support

2016-03-03 Thread Gunnar Morling
Interesting, do you know how do they do that? Run (unit) tests in a separate step after all modules has been compiled? It's notoriously hard to do with Maven, so I'm wondering how it's done. 2016-03-03 0:54 GMT+01:00 Sanne Grinovero : > I just learned that Travis makes it easy to compile with one