On 11 avr. 2013, at 01:27, Davide D'Alto dav...@hibernate.org wrote:
I think I would have put this contract on the dialect rather that the
provider. What was your reasoning?
The dialect seems involved in the conversion between the element used by the
data store (node, relationship,
I am currently working on a solution for dynamically adding new shards
to Hibernate Search (for example one per tenant with a list growing).
https://hibernate.atlassian.net/browse/HSEARCH-472
Things are going well but there is an interesting problem related to a
subsequent feature
IMHO passing the shard identifier in the Properties entries is a weak
solution in long term.
I shall prefer breaking SPI but no rational thoughts to back my out of
the box opinion.
Niko
2013/4/11 Emmanuel Bernard emman...@hibernate.org:
I am currently working on a solution for dynamically
Man your simple question is actually super complex.
Conclusion first: I think it's important we can always identify any
index just with a simple String, but you're very welcome to add some
kind of register indexName - StuffWeKnowAboutIt.
This has been biting in several forms. Let's recap the
Although this change fixes query lookup,
it adds horrible performance:
Running CapeDwarf cluster QueryTest:
with HSEARCH-1296
21:00:27,188 INFO
[org.hibernate.search.indexes.impl.DirectoryBasedIndexManager]
(http-/192.168.1.102:8080-1) HSEARCH000168: Serialization service Avro
Are you sure that the async version actually had applied all writes to the
index in the measured interval?
On Apr 11, 2013 8:13 PM, Ales Justin ales.jus...@gmail.com wrote:
Although this change fixes query lookup,
it adds horrible performance:
Running CapeDwarf cluster QueryTest:
with
You could try the new sync version but setting the blackhole backend on the
master node to remove the indexing overhead from the picture.
On Apr 11, 2013 8:39 PM, Sanne Grinovero sa...@hibernate.org wrote:
Are you sure that the async version actually had applied all writes to the
index in the
No, not in those 800ms, hence the failing test.
But if i add 2sec sleep in between delete and query,
the test passes.
Which is still 25x better. :)
On Apr 11, 2013, at 21:39, Sanne Grinovero sa...@hibernate.org wrote:
Are you sure that the async version actually had applied all writes to the
What do you mean?
On Apr 11, 2013, at 21:41, Sanne Grinovero sa...@hibernate.org wrote:
You could try the new sync version but setting the blackhole backend on the
master node to remove the indexing overhead from the picture.
On Apr 11, 2013 8:39 PM, Sanne Grinovero sa...@hibernate.org
I just made a change to help catch runtime problems that kept cropping
up. The change was to org.hibernate.mapping.Value#getColumnIterator.
The problem is that code in many modules (hem, envers) that actually
deals with mapping code were making a bad assumption here. The returned
iterator
One option just came to mind. Looking at the code, I have to assume
envers really just does not support formulas. Otherwise, all these
compile errors would eventually have resulted in runtime (CCE)
exceptions.
If that is really the case, I could add detection of that and throw a
more
There is a blackhole indexing backend, which pipes all indexing
requests /dev/null
Set this as an Infinispan Query configuration property:
default.worker.backend = blackhole
Of course that means that the index will not be updated: you might
need to adapt your test to tolerate that, but the
is this provider Google Fiber? :)
On Apr 11, 2013, at 11:04 PM, Steve Ebersole st...@hibernate.org wrote:
Sorry all but I won't be able to make meeting. In the middle of internet
connection provider setup. Of course they showed up right at time of
meeting :(
Anyway I just have cell
13 matches
Mail list logo
