Return-Path: Delivered-To: apmail-jakarta-lucene-user-archive@apache.org Received: (qmail 31358 invoked from network); 3 Jul 2003 00:27:18 -0000 Received: from exchange.sun.com (192.18.33.10) by daedalus.apache.org with SMTP; 3 Jul 2003 00:27:18 -0000 Received: (qmail 16018 invoked by uid 97); 3 Jul 2003 00:29:49 -0000 Delivered-To: qmlist-jakarta-archive-lucene-user@nagoya.betaversion.org Received: (qmail 16011 invoked from network); 3 Jul 2003 00:29:49 -0000 Received: from daedalus.apache.org (HELO apache.org) (208.185.179.12) by nagoya.betaversion.org with SMTP; 3 Jul 2003 00:29:49 -0000 Received: (qmail 31056 invoked by uid 500); 3 Jul 2003 00:27:16 -0000 Mailing-List: contact lucene-user-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Lucene Users List" Reply-To: "Lucene Users List" Delivered-To: mailing list lucene-user@jakarta.apache.org Received: (qmail 31044 invoked from network); 3 Jul 2003 00:27:15 -0000 Received: from web40903.mail.yahoo.com (66.218.78.200) by daedalus.apache.org with SMTP; 3 Jul 2003 00:27:15 -0000 Message-ID: <20030703002724.25846.qmail@web40903.mail.yahoo.com> Received: from [66.7.228.158] by web40903.mail.yahoo.com via HTTP; Wed, 02 Jul 2003 17:27:24 PDT Date: Wed, 2 Jul 2003 17:27:24 -0700 (PDT) From: Ali Rouhi Subject: Re: Query across multiple fields scenario not handled by "MultiFieldQueryParser" To: Lucene Users List In-Reply-To: <20030703002302.44676.qmail@web40907.mail.yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N --- Ali Rouhi wrote: > > --- Victor Hadianto wrote: > > > I need to perform a search for an expression in > > > multiple fields "as if" they were one field. > > > > Depending on your time requirment, you can as you > > have suggested yourself > > write your own QueryParser. However a simple hack > > will be to have an "all" > > field and simple reindex the data in F and G to > this > > "all" field. > > > > We have thought of this - but we index an enormous > amount of data (Terabytes distributed across many > linux boxes) and would prefer to save the disk > space. > However we may indeed end up doing what you suggest. Just a little clarification to the point I made regarding your suggestion. We do need to preserve the indexes under F and G and be able to search independently on them. This is why having an extra ALL field which contains contents of both F and G would involve extra disc usages. Ali > > > > little JavaCC expertise. Suggestions for solving > > the > > > problem at a higher level than the QueryParser > are > > of > > > course also very welcome. > > > > Well this is definitely not "higher" level than > > QueryParser :) > > This in itself is useful to know. I can now justify > having to learn JavaCC to my boss:). > > Thanks > Ali > > __________________________________ > Do you Yahoo!? > SBC Yahoo! DSL - Now only $29.95 per month! > http://sbc.yahoo.com > > --------------------------------------------------------------------- > To unsubscribe, e-mail: > lucene-user-unsubscribe@jakarta.apache.org > For additional commands, e-mail: > lucene-user-help@jakarta.apache.org > __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: lucene-user-unsubscribe@jakarta.apache.org For additional commands, e-mail: lucene-user-help@jakarta.apache.org