Hallo Daniel,
the reason that I used this way, is that the search mechanics currently
uses the IndexStore (getBasicExpressionFactory()) to create and execute queries.
It will be quite easy to use the indexing capabilities in an indexer based on the events. For the current implementation the IndexStore is the "EventListener" that triggers the indexing jobs, and we can of course use an other use a "real" listner.
The current indexing is transaction aware. Optional asynchronous indexing is one of the next steps I plan.
Duplicate indexing requests are filtered out.
I would say, if we get a lucene indexer running in the current design, it would not be to hard to reuse the implementation in a modified one.
Regards, Stefan
Daniel Florey wrote:
Hi Stefan, this is great news! I'm looking forward to check this out. Some months ago I've proposed a event triggered indexing based on event collections as this allows synchronous (transaction aware) and asynchronous indexing. This approach has some advantages as for example double events get deleted and only changes resources trigger indexing (Slide is calling some store methods multiple times in a single request). What about using this feature some day in the future? This approach would also allow indexing of properties and content independently from the used stores. Advantage: If multiple stores are mounted, the whole content can be searched with a single index. Disadvantage: If a DB-Store is mounted, the content will be searched by lucene indexes and not by database indexes. What do you think? I had some proposals worked out for a advanced search some months ago, but this is long time ago and as such is no more completely in my mind... Cheers, Daniel
"Slide Developers Mailing List" <[EMAIL PROTECTED]> schrieb am 18.10.04 12:14:42:
I now have added a first version to the cvs HEAD.
To use it simply add the following to your store defintion: <propertiesindexer classname="org.apache.slide.index.lucene.LucenePropertiesIndexer"> <parameter name="indexpath">index</parameter> </propertiesindexer>
Currenty I observed following indexing overhead (add 2500 (small)files and collection):
index size ~400Kbyte
without indexing ~7min with indexing ~11min
and on a faster machine
without indexing ~3.5min with indexing ~5.5min
Regards, Stefan
Stefan L�tzkendorf wrote:
Hi all,
I have a first implmentation of a propertiesindexer base on lucene.
Operators currenlty supported are: eq, lt, lte, gt, gte, is-collection, is-principal, and, or. Data types supported: String, Date, Int (Text will follow).
It is transaction aware in a limited sense: the index is updeted only if a transaction is commited.
It will be configurable for user defined properties (define data type and anylyzer).
I know that Darren is currently working on this stuff to so I'm thinking what to do. I would be glad to add this stuff as a new package in the stores section "org.apache.slide.index.lucene". An other option would be to add it to the proposals section (which is not my favorite (:-)).
What do you think? Regards, Stefan
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
__________________________________________________________ Mit WEB.DE FreePhone mit hoechster Qualitaet ab 0 Ct./Min. weltweit telefonieren! http://freephone.web.de/?mc=021201
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
