Hello,
I need some comments about the batch indexing API, so that I can
stabilize it and write the documentation;
I might even blog about it :-)
Here is the current sketch:
http://fisheye.jboss.org/browse/Hibernate/search/trunk/src/main/java/org/hibernate/search/Indexer.java?r=16967
Emmanuel I re
Hi,
I'm reviving previous discussion.
#3 Index copy
> this is what you are describing, copying the index using JGroups instead of
> my file system approach. This might have merits esp as we could diminish
> network traffic using multicast but it also require to rethink the master /
> slave modus
cool, fast answers! opened HSEARCH-384
I'll see what I can do about the context-dependent error messages, I'm
experimenting
with a String parameter to add some "component description", but I
have yet to verify if
it's enough for all cases.
2009/6/30 Emmanuel Bernard :
> Yes go ahead. The hard par
Yes go ahead. The hard part is to provide a meaningful error report
which depends on the context.
On Tue, 2009-06-30 at 14:50 +0200, Sanne Grinovero wrote:
> Hi,
> the code of Hibernate Search is very extensible, as nearly all
> internal modules are "overridable" by user provided implementation;
>
On Tue, 30 Jun 2009 14:50:54 +0200, Sanne Grinovero
wrote:
I am building a util class to get some consistency, and plan to unit
test this extensively to make sure it throws understandable exceptions
for the most common mistakes (hey, I need a public no-args
constructor! / not implementing th
Hi,
the code of Hibernate Search is very extensible, as nearly all
internal modules are "overridable" by user provided implementation;
this external classes are loaded by defining a short name (in case of
built-in extensions) or fully qualified names to load
whatever is on the classpath to replace