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 Se
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? N
Hi,
So, in OGM, for MongoDB, we also support running the tests with Fongo which
is an in-memory Java (more or less accurate) MongoDB implementation.
It has a cost as Fongo behaves differently and we have to disable
tests/implement different tests without any real benefits IMHO:
- it's easy to run
+1 as I proposed the same thing a long time ago: if it's not the real
thing we might as well mock all requests.
On 27 April 2017 at 16:40, Guillaume Smet wrote:
> Hi,
>
> So, in OGM, for MongoDB, we also support running the tests with Fongo which
> is an in-memory Java (more or less accurate) Mon
I don't mind removing it too much; but the idea behind it was no so
much our own testing but rather to let OGM users test their apps with
Fongo. I can see some value in that.
2017-04-27 17:46 GMT+02:00 Sanne Grinovero :
> +1 as I proposed the same thing a long time ago: if it's not the real
> thin
Yeah, frankly, they will be better served with an embedded MongoDB.
On Thu, Apr 27, 2017 at 5:51 PM, Gunnar Morling
wrote:
> I don't mind removing it too much; but the idea behind it was no so
> much our own testing but rather to let OGM users test their apps with
> Fongo. I can see some value i
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 prop
> 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 start
Hi Steve,
I'm finally getting back to this.
The assertion you suggest fails for SequenceHiLoGeneratorNoIncrementTest
because the test specifically sets increment_size=0. [1] I'm assuming the
legacy behavior should be preserved.
Another strange thing -- in NoopOptimer#generate, when incrementSize
I see that there are some OptimizerUnitTest tests failing. Please hold off
on looking at the PR until I figure out what's going on.
On Thu, Apr 27, 2017 at 5:46 PM, Gail Badner wrote:
> Hi Steve,
>
> I'm finally getting back to this.
>
> The assertion you suggest fails for SequenceHiLoGeneratorN
10 matches
Mail list logo
