> Looks really good, but two bits that i think might confuse people are > the implications that a "Query Parser" then invokes a series of search > components; and that "analysis" (and the pieces of an analyzer chain) > are what to lookups in the underlying lucene index. > > the first might just be the ambiguity of "Query" .. using the term > "request parser" might make more sense, in comparison to the "update > parsing" from the other side of hte diagram.
Thanks for commenting. Yea, the purpose is more to show a conceptual rather than actual relation between the different components, focusing on the flow. A 100% technical correct diagram would be too complex for beginners to comprehend, although it could certainly be useful for developers. I've removed the arrow between QueryParser and search components to clarify. The boxes first and foremost show that query parsing and response writers are within the realm of search request handler. > the analysis piece is a little harder to fix cleanly. you really want the > end of the analysis chain to feed back up to the searh components, and > then show it (most of hte search components really) talking to the Lucene > index. Yea, I know. Showing how Faceting communicate with the main index and spellchecker with its spellchecker index could also be useful, but I think that would be for another more detailed diagram. I felt it was more important for beginners to realize visually that analysis happens both at index and search time, and that the analyzers align 1:1. At this stage in the digram I often explain the importance of matching up the analysis on both sides to get a match in the index. -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com
