I've thought about a flag field, and I see no reason why that wouldn't
work quite well, it all depends, I suppose, upon how ugly it would
eventually get
But about caching, what does making a filter have to do with Lucene
caching? Sure, there exist Lucene filter caching classes, but
there's no
Unfortuantely at the moment we don't make good use of lucene caching, so
the setting up of the filter on startup doesn't really work for us at
the moment. Maybe just a general flag field instead of a hasname field
would work better and be more general. You could just fill this field
with any
Here's a way to do it using the XML query parser in contrib
1) Create this query.xsl file (note use of cached double negative filter)
xmlns:xsl="http://www.w3.org/1999/XSL/Transform";>
upperTerm="z"/>
I was going to suggest something about TermEnum/TermDocs, but
upon reflection that doesn't work so well because you have to
enumerate all the terms over all the docs for a field. Ouch.
But one could combine the two approaches. Don't index
any "special" values in your firstname or lastname fields.
Would a good solution be to insert a secret string into blank fields
that represents blank. That way you could search for:
firstname:(-Xd8fgrSjg) lastname:(-Xd8fgrSjg) some query string
Les
Les Fletcher wrote:
I like the idea of the filter since I am making heavy use of filters
for this par
I like the idea of the filter since I am making heavy use of filters for
this particular query, but how would one go about constructing it
efficiently at query time? All I can see is hacking around not being
able to use the * as the first character.
Les
Erick Erickson wrote:
You could crea
You could create a Lucene Filter that had a bit for each document that
had a first or last name and use that at query time to restrict your
results appropriately. You could create this at startup time or at
query time. See CachingWrapperFilter for a way to cache it.
Another approach would be to
