I’ve seen customers essentially rewriting the mass indexer logic in Spring
Batch because it offered retries, was more aligned with what they used and they
needed a tiny query twist in the current mass indexer code that does not expose
enough.
So I am not too concerned about a performance gap.
Hi,
2016-02-24 11:45 GMT+01:00 Sanne Grinovero :
> It sounds interesting, but bear with me I'm not familiar with it so
> I'll throw out some doubts.
>
> Will it work without a JEE container?
> I guess some implementations might be embeddable, but still how simple
> would that be for the user?
Yes
It sounds interesting, but bear with me I'm not familiar with it so
I'll throw out some doubts.
Will it work without a JEE container?
I guess some implementations might be embeddable, but still how simple
would that be for the user?
Note that we already allow rebuilding the index via JMX commands
good idea
> On 24 Feb 2016, at 10:56, Vlad Mihalcea wrote:
>
> +1
>
> Sounds like a good idea.
>
> On Wed, Feb 24, 2016 at 11:39 AM, Gunnar Morling
> wrote:
>
>> Hi,
>>
>> I've been contemplating the idea of creating a JSR-352-style batch
>> application for re-indexing one or more entity ty
+1
Sounds like a good idea.
On Wed, Feb 24, 2016 at 11:39 AM, Gunnar Morling
wrote:
> Hi,
>
> I've been contemplating the idea of creating a JSR-352-style batch
> application for re-indexing one or more entity types in Hibernate
> Search.
>
> Functionally, it'd be the same as the current mass i
Hi,
I've been contemplating the idea of creating a JSR-352-style batch
application for re-indexing one or more entity types in Hibernate
Search.
Functionally, it'd be the same as the current mass indexer, but using
JSR 352 would provide some nice benefits:
* Operation through standard batch inte
