Yeah, thanks a lot for your help! I'm using the release version of Lucene version 1.2.
> not all your queries are truly "WildcardQuery"'s though. look at the > class it constructed to get a better idea of what is happening. Yeah, I printed the queries out to see what was going on and noticed that. I used wildcard in the subject as a sort of general description of what I was after rather than its technical meaning to lucene, but I was curious about why I was getting the query types I was getting. > your default field for QueryParser is "property*"? Odd field name, or > is the output fishy? I'm a bit confused by the "property*:" there. > I'm assuming you're outputting the Query.toString here. That's just the Query.toString, yeah. I didn't set any default fields to property* so whatever it's spitting out comes from the QueryParser. >> Query> name:amb propert* and city:"south san fran*" > you're getting hits on the wildcard match at least, and probably on > name field "amb" as well. again, phrase queries don't support > wildcards like you've done here with "south san fran*" so you're not > matching anything with that. Ok... What's the correct procedure for doing a multi-word wildcard where I want it to begin with "south san fran" but not get anything else that contains "south" or "san"? Just and together the south, san, and fran? Although this might produce good results, my understanding was that booleans retrieve all matches and store them in memory then resolve the booleans. If I use the term "san" to search California, I'm going to need a lot of memory to store all of the temporary results...! Or is that only true when doing booleans on different fields? If so, I think we have our solution! :) > I'm still confused by the output of propert*: here - are you using > the CVS version of Lucene? The honest to goodness 1.2 release. :) > I hope my above analysis helps. I may not be perfectly right on > everything, but should be relatively close at identifying the issues. > Fixing it is more up to how you want to deal with it. Perhaps a custom > QueryParser is more what you're after. Well, i think the real key piece of information was to drop the quotes to avoid the phrase queries. Thanks! --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
