lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Carlson <carl...@bookandhammer.com>
Subject Re: [Bug 12137] New: - Can '*' or '?' symbol be used as the first character of a search?
Date Fri, 30 Aug 2002 04:48:25 GMT
I agree that end users (or app users) will not worry about if a query 
is expensive, they are just trying to get done what they need to get 
done.

But, I would also say that we should not hinder app developers from 
providing the functionality their app users need. If a query takes 5 
min, but it is the most efficient way to get the information they need, 
don't you think that this is the app developers choice, since they are 
supporting the app user.

I think it is the responsibility of the app developer, not the Lucene 
developer, to provide the infrastructure required to meet a given set 
of requirements. I would agree that it is the Lucene Developer's job to 
inform the app developer about the tool they are using, but I would 
also say that since we don't know what problem an app developer is 
trying to solve, and what resources they have so solve it Lucene 
developers should try to provide tools to solve it, with the 
appropriate information about using those tools.

If many app developers wants functionality, why wouldn't we offer a 
configuration to solve their problem? Their response time may meet 
their requirements. If they have the world as users and must have a 
quick response time, then the app developers should make the decision 
to not use a expensive query.

This happens all the time with other development environments. For 
example, the default for Tomcat is to check if a jsp page should be 
checked and recompiled on the fly if it's changed. This feature is 
great for development, but slows down a production system. They did 
however include the feature as a default.

Also, you are making an argument that we shouldn't include 
functionality, but the app developer will implement the functionality 
(as has been shown) and potentially not know the ramifications of what 
they have done (also potentially has has been shown). If we provide a 
configuration for an expensive query and provide details about why it's 
expensive, then this will put more information in the hands of the app 
developer to either include it or not in their query syntax. It won't 
just be an unimplemented feature, but a feature that should be used 
with caution.

The question is not if app developers will implement expensive query 
features, but if they do how much will they understand what they have 
developed and understand the limitations of Lucene.

--Peter



On Thursday, August 29, 2002, at 08:18 PM, Brian Goetz wrote:

> We went through this with range queries, too.  My philosophy on the 
> query parser is "anything that requires documentation must not belong 
> in it", since 99.5% of the users will not only not read the 
> documentation, but not realize any exists.


--
To unsubscribe, e-mail:   <mailto:lucene-dev-unsubscribe@jakarta.apache.org>
For additional commands, e-mail: <mailto:lucene-dev-help@jakarta.apache.org>


Mime
View raw message