Hi,
thanks for your input. Please see my comments inline.
Wojtek
Adriano Crestani:
Hi Wojtek,
Some comments inline:
> Found elements would be stored with current document data.
I don't see any reason for storing the entire document content in the
index, why would you do that? Couldn't you just store some URI that
would point to the original file?
I was trying to say here that found elements should be remembered. We
wouldn't store anything but references to them.
*> All* | All above fields to provide non-filter queries.
You don't need to do it, if you do, you will basically duplicate the
posting list size in the index. To reproduce what you want, the field
"all" should be available only for querying purposes, for example, the
user could type 'all:store' in the query, and before processing the
query it could be expanded to all the "searchable" fields:
component:store contribution:store...etc. It's a common practice on
unstructured data world, it's so common that Lucene has a query parser
for that called MultiFieldQueryParser : )...I think you already said it
here:
> none (all document fields would be used to search)
> regular expressions
Yes, this is probably what I wanted to achieve :)
Can you give me some example of regular expressions?
I mean queries enhaned by regex syntax, ie. "Component[A-C]\.component"
to find everywhere components from A to C.
I plan to use here RegexQuery instead one of QueryParsers and as I see
regular expressions cannot be used in standard Lucene syntax, so those
searches wouldn't be as powerfull as standard ones. I mean you won't use
logic operators and multiple fields and etc., it would be limited only
to one or all fields and regex query string.
I liked your presentation idea : )
Architectural outline session is also very complete : )
Good luck ; )
Adriano Crestani
