Mailing-List: contact java-user-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: java-user@lucene.apache.org
Received-SPF: pass (nike.apache.org: local policy)
To: <java-user@lucene.apache.org>
From: "Itamar Syn-Hershko" <itamar@divrei-tora.com>
Subject: Why Lucene has to rewrite queries prior to actual searching?
Date: Tue, 8 Apr 2008 00:13:09 +0300
Message-ID: <4DD28DFBE83445D39F0177E2FC3C4C68.MAI@mail.livedns.co.il>
MIME-Version: 1.0
Content-Type: multipart/mixed;
	boundary="--=_Part_83B3577A0CAC48F4A77D3DFB7F7766CD"

----=_Part_83B3577A0CAC48F4A77D3DFB7F7766CD
Content-Type: text/plain; charset="windows-1255"
Content-Transfer-Encoding: quoted-printable

Hi all,
 
Can someone from the experts here explain why Lucene has to get a "rewritten" query for the Searcher - so Phrase or Wildcards queries have to rewrite themselves into a "primitive" query, that is then passed to Lucene to look for=3F
I'm probably not familiar too much with the internals of Lucene, but I'd imagine that if you can inflate a query using wildcards via xxxxQuery sub classing, you could as easily (=3F) have some sort of Filter mechanism during the search, so that Lucene retrieves the Position vectors for all the terms that pass that filter, instead of retrieving only the position data for deterministic terms (with no wildcards etc.). If that was possible to do somehow, it could greatly increase the searchability of Lucene indices by using RegEx (without re-writing and getting the dreaded MaxClauseCount error) and similar.
 
Would love to hear some insights on this one.
 
Itamar.


----=_Part_83B3577A0CAC48F4A77D3DFB7F7766CD
Content-Type: text/plain; charset=us-ascii

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org
----=_Part_83B3577A0CAC48F4A77D3DFB7F7766CD--