Re: Bug? QueryParser may not correctly interpret RangeQuery text

> Should date fields be tokenized? Current the Field.Keyword(String, Date) > constructor has the Date tokenized, but this doesn't seem right. No, I thought I copied from Keyword so it wouldn't be tokenized. Did I screw it up? -- To unsubscribe, e-mail: For additiona

Re: Bug? QueryParser may not correctly interpret RangeQuery text

I am finally getting a few moments to look at this. Should date fields be tokenized? Current the Field.Keyword(String, Date) constructor has the Date tokenized, but this doesn't seem right. --Peter On 6/24/02 5:09 PM, "Brian Goetz" <[EMAIL PROTECTED]> wrote: >> Just curious what the status of

Re: Bug? QueryParser may not correctly interpret RangeQuery text

Brian Goetz wrote: > The only part I'm not sure about here is what to do with negative > numbers. I'm sure there's some representation which gives the desired > result when sorted lexicographically; Doug? Two's complement comes to mind. Convert to two's complement and print as hex, padded to

Re: Bug? QueryParser may not correctly interpret RangeQuery text

> > Also, we talked about adding numeric ranges too. First we'd need a > > NumberField class and "constructor", similar to DateField, and then > > we'd want to use NumberFormat to see if the elements in the range query > > are of the right format. The only part I'm not sure about here is what to

Re: Bug? QueryParser may not correctly interpret RangeQuery text

Brian, This sounds great. I'll have a look at it and hopefully have some time to help finish it up. Although I am a bit behind on a few Lucene project myself. --Peter On 6/24/02 5:09 PM, "Brian Goetz" <[EMAIL PROTECTED]> wrote: >> Just curious what the status of this issue is, as the discuss

Re: Bug? QueryParser may not correctly interpret RangeQuery text

> Just curious what the status of this issue is, as the discussion seems > to have stopped. I checked in a first cut at this facility: - Field.Keyword(String, Date) "constructor", which uses DateField format; - Extensions to query parser as discussed earlier; - test cases. More work nee

Re: Bug? QueryParser may not correctly interpret RangeQuery text

> The first part of this is easy: just add new Field "constuctor" methods > that take Date and number parameters, e.g.: >Field.Keyword(String name, Date value); >Field.Keyword(String name, int value); By the way, is there any NumberField class, which provides String <--> int support, in

Re: Bug? QueryParser may not correctly interpret RangeQuery text

Awesome. --Peter On 6/6/02 6:05 AM, "Brian Goetz" <[EMAIL PROTECTED]> wrote: >> I 100% agree with you about having actual field types, I just don't know >> what the ramifications are and haven't looked. I was hoping Doug would chime >> in and make it easy for us. > > Doug's suggestion seemed O

Re: Bug? QueryParser may not correctly interpret RangeQuery text

> I 100% agree with you about having actual field types, I just don't know > what the ramifications are and haven't looked. I was hoping Doug would chime > in and make it easy for us. Doug's suggestion seemed OK to me as a first and easy cut at this. Sounds like we've got agreement on TO as a

RE: Bug? QueryParser may not correctly interpret RangeQuery text

esday, June 05, 2002 9:25 AM > To: 'Lucene Developers List' > Subject: RE: Bug? QueryParser may not correctly interpret RangeQuery > text > > > Hey All, > > > I can confirm your suspicion about the poor performance of > > object serialization and urge

Re: Bug? QueryParser may not correctly interpret RangeQuery text

what about timestamp and do a number search or range search ( "[123 124]" )?? -- On Wed, 05 Jun 2002 00:01:46 Peter Carlson wrote: >I guess from my perspective we are at > >field:[->] > >The delimiter is not yet defined, but the options currently discussed are >- >-> >; >: >| >> > >The probl

RE: Bug? QueryParser may not correctly interpret RangeQuery text

> To: Lucene Developers List > > Subject: Re: Bug? QueryParser may not correctly interpret > RangeQuery > > text > > > > > > Brian Goetz wrote: > > > I still want to see Date and Number fields supported as > > basic types in > > > the Fi

RE: Bug? QueryParser may not correctly interpret RangeQuery text

; To: Lucene Developers List > Subject: Re: Bug? QueryParser may not correctly interpret RangeQuery > text > > > Brian Goetz wrote: > > I still want to see Date and Number fields supported as > basic types in > > the Field class, rather than "use a String in this magic

Re: Bug? QueryParser may not correctly interpret RangeQuery text

Brian Goetz wrote: > I still want to see Date and Number fields supported as basic types in > the Field class, rather than "use a String in this magic date format". The first part of this is easy: just add new Field "constuctor" methods that take Date and number parameters, e.g.: Field.Keywor

Re: Bug? QueryParser may not correctly interpret RangeQuery text

Brian, I 100% agree with you about having actual field types, I just don't know what the ramifications are and haven't looked. I was hoping Doug would chime in and make it easy for us. It would be nice to have it working though. I vote +1 for " TO " And for the format into date then number meth

Re: Bug? QueryParser may not correctly interpret RangeQuery text

> I guess from my perspective we are at > > field:[->] > > The delimiter is not yet defined, but the options currently discussed are > - > -> > ; > : > | > > > > The problem with - and : is that they may be part of a date format. How about " TO " as the delimiter? > The action taken by the Qu

Re: Bug? QueryParser may not correctly interpret RangeQuery text

I guess from my perspective we are at field:[->] The delimiter is not yet defined, but the options currently discussed are - -> ; : | > The problem with - and : is that they may be part of a date format. The action taken by the QueryParser would depend on the type of field we were using (if th

Re: Bug? QueryParser may not correctly interpret RangeQuery text

Hello, Just curious what the status of this issue is, as the discussion seems to have stopped. --- "Eric D. Friedman" <[EMAIL PROTECTED]> wrote: > Instead of reinventing the wheel for representing dates, how about > using an existing standard? ISO 8601 defines a simple lexical > representation

RE: Bug? QueryParser may not correctly interpret RangeQuery text

or novices, and insufficiently rich for experts. On this point, I suspect that we're in violent agreement. Eric > -Original Message- > From: Brian Goetz [mailto:[EMAIL PROTECTED]] > Sent: Sunday, June 02, 2002 9:52 PM > To: Lucene Developers List > Subject: Re: Bug?

Re: Bug? QueryParser may not correctly interpret RangeQuery text

I think that it is fairly intuitive depending on what functionality people are trying to use. For just a standard set of terms the big question is what should the default boolean operator be OR or AND. For the rest, it seems fairly "standard" when looking at other search engine syntax. Also, whe

Re: Bug? QueryParser may not correctly interpret RangeQuery text

>I agree with Alex -- the QueryParser's syntax has become >at least as obfuscated as SQL, probably more so. It may >have started out simple, but it's not simple anymore. But is that an argument to let it go "all the way" to complete obfuscation, or simplify it so that it is more in line with i

Re: Bug? QueryParser may not correctly interpret RangeQuery text

I agree with Alex -- the QueryParser's syntax has become at least as obfuscated as SQL, probably more so. It may have started out simple, but it's not simple anymore. Eric On Sun, 2 Jun 2002, Alex Murzaku wrote: > It's true that the unsofisticated end-user would not > use SQL, but between rang

Re: Bug? QueryParser may not correctly interpret RangeQuery text

Instead of reinventing the wheel for representing dates, how about using an existing standard? ISO 8601 defines a simple lexical representation for dates, times (with optional millisecond precision), and timezones that is easy to implement. This is what's used in the XML Schema "dateTime" dataty

Re: Bug? QueryParser may not correctly interpret RangeQuery text

>It's true that the unsofisticated end-user would not >use SQL, but between range (inclusive, exclusive), >boolean, fuzzy, etc., the simple query parser you have >is evolving into something more complex than SQL. Which is a reasonable argument that range queries are outside the scope of what th

Re: Bug? QueryParser may not correctly interpret RangeQuery text

It's true that the unsofisticated end-user would not use SQL, but between range (inclusive, exclusive), boolean, fuzzy, etc., the simple query parser you have is evolving into something more complex than SQL. While SQL supports them with key words, we are getting into an endless quest for unused c

Re: Bug? QueryParser may not correctly interpret RangeQuery text

> Maybe we could even throw in full support for SQL like > SELECT, WHERE, etc. As far as I remember, JavaCC used > to have an SQL parser as well, so, I assume we would > just need the translation to a Lucene query. I am sure > everybody would appreciate using some syntax with > which they are alre

Re: Bug? QueryParser may not correctly interpret RangeQuery text

How about just the SQL "BETWEEN ... AND ..."? Maybe we could even throw in full support for SQL like SELECT, WHERE, etc. As far as I remember, JavaCC used to have an SQL parser as well, so, I assume we would just need the translation to a Lucene query. I am sure everybody would appreciate using s

Re: Bug? QueryParser may not correctly interpret RangeQuery text

I like this idea of [GOOP:GOOP] as it gives the most flexibility. However, this requires the field to have a known characteristic like a date field, number field or text field correct? If you just use the static Field.Date this would require adding a new attribute the field class? I like this idea

Re: Bug? QueryParser may not correctly interpret RangeQuery text

> > How about: > > > > DATE = -nn-nn > > NUMBER = n* > > RANGE = [ DATE : DATE ] | [ NUMBER : NUMBER ] > > > > An alternate, less parse-oriented approach would be this: > > RANGE = [ GOOP : GOOP ] > > where > > GOOP = any string of letters/numbers not containing : or ]. > > I'd go

Re: Bug? QueryParser may not correctly interpret RangeQuery text

Hello, --- Brian Goetz <[EMAIL PROTECTED]> wrote: > > I think we should have a Date format or formats and then convert > them use > > the DateField to the Lucene date format. > > OK, Common date formats could include: > mm/dd/yy > mm/dd/ > -mm-dd (2002-05-01) > -mmm-dd (2002

Re: Bug? QueryParser may not correctly interpret RangeQuery text

> I think we should have a Date format or formats and then convert them use > the DateField to the Lucene date format. OK, Common date formats could include: mm/dd/yy mm/dd/ -mm-dd (2002-05-01) -mmm-dd (2002-May-01) The latter two seem more sensible as they are non US-centri

Re: Bug? QueryParser may not correctly interpret RangeQuery text

> Date formats to include might be > Mm/dd/ where these are all (this is very US centric but > could > easily be converted for other countries) > > MMM dd, (where MMM is JAN, FEB, ...) > > Yyyy/mm/dd (be able to know by 4 start) > > Others dd.MM.. -MM-dd Otis

Re: Bug? QueryParser may not correctly interpret RangeQuery text

Sounds good. I think we should have a Date format or formats and then convert them use the DateField to the Lucene date format. Date formats to include might be Mm/dd/ where these are all (this is very US centric but could easily be converted for other countries) MMM dd, (where MMM is

Re: Bug? QueryParser may not correctly interpret RangeQuery text

> This is something I'd like to get working on so if you have any pointers I'd > spend the time to get the work done. The technical part is generally pretty easy, once we decide what we actually want to do. The problem is when we don't really know what we want to accept. Lets start with comin

Re: Bug? QueryParser may not correctly interpret RangeQuery text

That sounds great. I really know nothing about JavaCC so I was trying to figure a way of not using the StandardTokenizer to tokenize the code. This is something I'd like to get working on so if you have any pointers I'd spend the time to get the work done. Thanks --Peter On 6/1/02 3:43 PM, "B

Re: Bug? QueryParser may not correctly interpret RangeQuery text

> What do people think the right way to handle this issue for the range > queries? My suggestion is to do a indexOf() for "-" and create the one or > two tokens. That is, don't use the analyzer to determine what the tokens are > here. Is there a problem with this? We can also use JavaCC's lexical

Bug? QueryParser may not correctly interpret RangeQuery text

I am trying to get date range searching use the range query (maybe a bad choice vs. DateFilter, but I wanted to be able to use it from the query string). So I type in a string like date:[0czi1ceuk-0d0ouet2k] When I run this through the QueryParser it return only 1 term. That is the query gets co