It took me a couple of days, but this is added to JIRA
Erick
OK, I get it now. Obviously I didn't read your response as you meant it and
was focusing on the optimization part.
I'd also agree that using the most specific tool for the task is better
design. There's also an argument that "I'd rather have a library fail than
do something non-obvious". I'll leav
I don't mean literally that WildcardQuery would morph into a
TermQuery, but rather "behave" like it by simply doing what it
currently does but without the string index exception that currently
is thrown. It wouldn't take any additional clockticks, per se, I
don't think - it'd just behave a
8 apr 2006 kl. 19.04 skrev Erick Erickson:
I have to disagree.
Optimization where it really doesn't count is, in my experience, bad.
Period.
My intent was not to ephasise on optimization. The waste of
clockticks is just a side effect from what I consider bad design.
WildcardQuery and T
I have to disagree. Nowhere in the javadoc is this condition noted. There is
no way for a user to know that this is a restriction, and forcing developers
to find this by having a program fail, even with a better error message,
is...er...unfortunate. Even if this were in the javadoc, I still have to
8 apr 2006 kl. 13.06 skrev Erik Hatcher:
Feel free to log this as a bug report in our JIRA issue tracker.
It seems like a reasonable change to make, such that a
WildcardQuery without a wildcard character would behave like
TermQuery.
-1
Even though very few, it is a waste of clockticks.
Feel free to log this as a bug report in our JIRA issue tracker. It
seems like a reasonable change to make, such that a WildcardQuery
without a wildcard character would behave like TermQuery.
Erik
On Apr 7, 2006, at 10:28 AM, Erick Erickson wrote:
So I'm trying to do silly stuff,
