I personally like your effort, but technically I would disagree.
The SOLR project, and the project I am working on, DBSight, have an detached approach which is implementation agnostic, no matter if it's java, ruby, php, .net. The return results can be a rendered HTML, JSON, XML. I don't think you can be more flexible than that. If creating an new index takes 5 minutes without any coding, you can create something more creative.
From business side, you don't need to worry about indexing when
designing a system. New requirement may come. It's very hard trying to anticipate all the needs. Technically, detached approach gives more flexible on resources like CPU, memory, hard drive. For example, if your index grows large, say 1G, indexing can take hours with merging, I am not sure how compass or hibernate/lucene handles it. Need to re-write code at that time? I actually feel it's a dangerous trap.
I've introduced a session.index() which forces the (re)indexing of the document
So does it mean you need to write some code to fix the index if it's crashed?
What do you mean by multithread safe? The indexing? the indexing is multithread safe in the Hibernate Lucene integration
The indexing can be threadsafe. But will it affect the searching? With many files changing and merging, if you cache the searcher. the searching will have "read passed EOF" exceptions. If you don't cache the searcher, you will loose the built-in caching, FieldCacheImpl, in Lucene.
The query process? the query doesn't have to since you query on a give session (aka user conversation), so no multithread threat here.
So you are not caching searcher. -- Chris Lu ------------------------- Instant Full-Text Search On Any Database/Application site: http://www.dbsight.net demo: http://search.dbsight.com On 11/3/06, Emmanuel Bernard <[EMAIL PROTECTED]> wrote:
Hi, What exactly are your concerned about the "non-detached" approach (see below)? Chris Lu wrote: > > I would prefer a detached approach instead of Hibernate or EJB's > approach, which is kind of too tightly coupled with any system. How to it is probably going to be couple with yours ;-) > rebuild if the index is corrupted, or you have a new Analyzer, or I've introduced a session.index() which forces the (re)indexing of the document > schema evolves? How to make it multi-thread safe? What do you mean by multithread safe? The indexing? the indexing is multithread safe in the Hibernate Lucene integration The query process? the query doesn't have to since you query on a give session (aka user conversation), so no multithread threat here. --------------------------------------------------------------------- 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]
