On Jun 10, 2004, at 10:37 PM, Terry Steichen wrote:
Speaking for myself, only a small number of my code modules currently treat
"null" as the open-ended range query term parameter. If the syntax change
from 'null' --> '*' was deemed otherwise desirable and the syntax transition
made very clearly, I could personally adjust to it without too much
difficulty.

I agree that the proposed '*' syntax does seem more logical. If a change to
that syntax were made such that the old "null" syntax for the upper bound
was retained for backward compatibility, such a transition would be
completely painless.

Just to clarify, since Terry's response implies this is not understood.... there is *nothing* special about "null" currently. It is simply being treated as term text. So adding special "*" handling would NOT change how "null" currently works.


In June of 2002 (!) "null" and "NULL" (and "nULL", "Null", etc) were removed as being special from what I see in the diff.

Furthermore, to achieve the proposed "*" handling, you can do this yourself now by subclassing QueryParser and overriding getRangeQuery:

  protected Query getRangeQuery(String field, Analyzer analyzer,
                                String part1, String part2,
                                boolean inclusive)
      throws ParseException {

      return new RangeQuery(
          "*".equals(part1) ? null : new Term("field", part1),
          "*".equals(part2) ? null : new Term("field", part2),
          inclusive);
  }

(a little more is needed if you want to keep the date range handling).

Note, you cannot do field:[* TO *] to make it wide-open - RangeQuery does not allow this.

My proposal is this (_after_ 1.4 goes final):

  - Add the above logic to QueryParser.

- Modify RangeQuery.toString to output the "*" when the term is null, and also if the start term is "" (RangeQuery's constructor modifies the beginning term to "" if it is null).

If there are no objections to this plan, I'll add this as a Bugzilla issue as a reminder. I don't want to touch 1.4's codebase - no point in adding a feature at this stage that can already be achieved with the simple code above.

        Erik


--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to