Sanyi writes: > Enumerating the terms using WildcardTermEnum and an IndexReader seems to be > too buggy to use.
If there's a bug, it should be tracked down, not worked around... But it looks ok to me: import org.apache.lucene.analysis.standard.StandardAnalyzer; import org.apache.lucene.index.*; import org.apache.lucene.document.*; import org.apache.lucene.store.*; import org.apache.lucene.search.*; public class LuceneTest { public static void main(String[] args) throws Exception { RAMDirectory dir = new RAMDirectory(); IndexWriter writer = new IndexWriter(dir, new StandardAnalyzer(), true); Document doc = new Document(); doc.add(new Field("foo", "blabla etc.. etc... c0la c0ca caca ccca", true, true, true)); writer.addDocument(doc); writer.close(); IndexReader reader = IndexReader.open(dir); WildcardTermEnum enum = new WildcardTermEnum(reader, new Term("foo", "c??a")); do { System.out.println(enum.term().text()); } while ( enum.next() ); WildcardQuery wq = new WildcardQuery(new Term("foo", "c??a")); Query q = wq.rewrite(reader); System.out.println(q.toString()); reader.close(); } } gives c0ca c0la caca ccca foo:c0ca foo:c0la foo:caca foo:ccca The only bug I see is in the docs, that claims enum.term() to be invalid before the first call to next() which does not seem to be the case. So if you use while ( enum.next() ) { ... } you will loose the first term, whatever it is. Looking at the sources I find that this behaviour is shared by FuzzyTermEnum. Both implementations of the abstract FilteredTermEnum class call setEnum at the end of the constructor, which prepares the first result. Morus --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]