is this provider Google Fiber? :)
On Apr 11, 2013, at 11:04 PM, Steve Ebersole 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 connection atm.
> __
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 t
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 meaning
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 ac
What do you mean?
On Apr 11, 2013, at 21:41, Sanne Grinovero 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" wrote:
>> Are you sure that the async
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 wrote:
> Are you sure that the async version actually had applied all writes to the
> index in the mea
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" wrote:
> Are you sure that the async version actually had applied all writes to the
> index in the measured interva
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" wrote:
> Although this change fixes query lookup,
> it adds horrible performance:
>
> Running CapeDwarf cluster QueryTest:
>
> with HSEARCH-1296
>
> 2
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
SerializationP
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 dif
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 connection atm.
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.or
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 :
> I am currently working on a solution for dynamically adding new shards
> to Hib
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
https://hibern
On 11 avr. 2013, at 01:27, "Davide D'Alto" 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, document, etc.
14 matches
Mail list logo