Mailing List Archive

NotQuery elsewhere (Minion)
Just wandered across a blog post about someone else's implementation
of NotQuery, and why they thougth it was a good idea:

http://blogs.sun.com/searchguy/entry/minion_and_lucene_query_languages

I'm not familiar with Minion, but I like the impression of it's
philosophy that I get from this and its adjoining blog posts. You're
stuck with me, though, as I vastly prefer the Perl/C combo to straight
Java. :)

Nathan Kurz
nate@verse.com

_______________________________________________
KinoSearch mailing list
KinoSearch@rectangular.com
http://www.rectangular.com/mailman/listinfo/kinosearch
Re: NotQuery elsewhere (Minion) [ In reply to ]
On May 9, 2008, at 1:40 PM, Nathan Kurz wrote:

> Just wandered across a blog post about someone else's implementation
> of NotQuery, and why they thougth it was a good idea:
>
> http://blogs.sun.com/searchguy/entry/minion_and_lucene_query_languages

Well, KS trunk now has NOTQuery, along with the other Query subclasses
we hammered out: ANDQuery, ORQuery, and RequiredOptionalQuery. Those
should make it possible to implement a wider variety of parsing
behaviors.

I can't imagine that you'll ever stay happy with any default parsing
behavior, though, Nathan. I don't think this discussion ends until
you have your own that you can tweak.

> I'm not familiar with Minion, but I like the impression of it's
> philosophy that I get from this and its adjoining blog posts. You're
> stuck with me, though, as I vastly prefer the Perl/C combo to straight
> Java. :)


I'll try to enjoy the good times while they last.

Marvin Humphrey
Rectangular Research
http://www.rectangular.com/


_______________________________________________
KinoSearch mailing list
KinoSearch@rectangular.com
http://www.rectangular.com/mailman/listinfo/kinosearch
Re: NotQuery elsewhere (Minion) [ In reply to ]
On Fri, May 9, 2008 at 4:08 PM, Marvin Humphrey <marvin@rectangular.com> wrote:
>> Just wandered across a blog post about someone else's implementation
>> of NotQuery, and why they thougth it was a good idea:
>>
>> http://blogs.sun.com/searchguy/entry/minion_and_lucene_query_languages
>
> Well, KS trunk now has NOTQuery, along with the other Query subclasses we
> hammered out: ANDQuery, ORQuery, and RequiredOptionalQuery. Those should
> make it possible to implement a wider variety of parsing behaviors.

Yes, I've been watching the patches fly by on the commit list. It
seems like a great direction to me. I felt all warm and fuzzy when I
saw ReqOptQuery getting renamed.

> I can't imagine that you'll ever stay happy with any default parsing
> behavior, though, Nathan.

True, but I'm not worried at all about the default behaviour. Writing
a custom parser is the least of my worries. I'll be excited to be able
to work within the existing framework, and it looks like things are
headed in that direction.

>> I'm not familiar with Minion, but I like the impression of it's
>> philosophy that I get from this and its adjoining blog posts. You're
>> stuck with me, though, as I vastly prefer the Perl/C combo to straight
>> Java. :)
>
> I'll try to enjoy the good times while they last.

I trust by the absence of smiley-marks that no sarcasm was intended on
your part. :) I should have also added that I also really like your
philosophy of KinoSearch, even more so as it diverges from Lucene's
architecture. And your Boilerplater layer is really getting smooth.
More compliments available on demand. :)

Nathan Kurz
nate@verse.com

_______________________________________________
KinoSearch mailing list
KinoSearch@rectangular.com
http://www.rectangular.com/mailman/listinfo/kinosearch