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
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 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
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
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
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
+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
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
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
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
10 matches
Mail list logo
