lucene-java-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Lance Norskog <goks...@gmail.com>
Subject Re: 3.0.3 Contrib Query Parser : Custom Field Name Builder
Date Sun, 09 Jan 2011 04:07:55 GMT
Bravo!

On Fri, Jan 7, 2011 at 10:39 PM, Adriano Crestani
<adrianocrestani@gmail.com> wrote:
> I created a JIRA to fix this problem:
> https://issues.apache.org/jira/browse/LUCENE-2855
>
> On Sat, Jan 8, 2011 at 1:32 AM, Adriano Crestani
> <adrianocrestani@gmail.com>wrote:
>
>> Hi Christopher,
>>
>> Thanks for raising this problem, I always thought a little bit strange to
>> use CharSequence as map key. Then a just did a little bit of research and
>> found this on CharSequence javadoc:
>>
>> "This interface does not refine the general contracts of the equals<http://download.oracle.com/javase/1.5.0/docs/api/java/lang/Object.html#equals(java.lang.Object)>
>>  and hashCode<http://download.oracle.com/javase/1.5.0/docs/api/java/lang/Object.html#hashCode()>
>>  methods. The result of comparing two objects that implement CharSequence is
>> therefore, in general, undefined. Each object may be implemented by a
>> different class, and there is no guarantee that each class will be capable
>> of testing its instances for equality with those of the other. It is
>> therefore inappropriate to use arbitrary CharSequence instances as
>> elements in a set or as keys in a map."
>>
>> So I think every Set or Map that uses CharSequence on contrib queryparser
>> should be forced to use String instead. I think there is no need to change
>> any API, we just need to make sure that toString() is invoked on the
>> CharSequence object before adding it to any Set or Map, this way we can fix
>> this problem for next 3.x release. However, for 4.x, we should ideally
>> change every API that receives or return Map<CharSequence,...> or
>> Set<CharSequence> to use only String.
>>
>>
>>
>> On Fri, Jan 7, 2011 at 8:44 PM, Christopher St John <ckstjohn@gmail.com>wrote:
>>
>>> I'm trying to:
>>>
>>>  StandardQueryTreeBuilder b = …;
>>>  b.setBuilder( "myfield", fieldSpecificBuilder);
>>>
>>> In the debugger I see that the builder is registered in the
>>> QueryTreeBuilder's fieldNameBuilders map.
>>>
>>> When parsing, QueryTreeBuilder.getBuilder tries to look
>>> up the builder by using the FieldableNode's field but the
>>> debugger says the node's field is an UnescapedCharSequence,
>>> not a String, and the lookup fails.
>>>
>>> Registering the builder with an UnescapedCharSequence
>>> for the name instead of a String doesn't seem to help,
>>> presumably because UCS doesn't have a hash an equals
>>> or hash method.
>>>
>>> Suggestions? I've worked around it by registering a class
>>> based builder, checking for the field name and either
>>> delegating to the original builder or doing my custom
>>> processing, but it's a little awkward.
>>>
>>> -cks
>>>
>>> --
>>> Christopher St. John
>>> http://artofsystems.blogspot.com
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
>>> For additional commands, e-mail: java-user-help@lucene.apache.org
>>>
>>>
>>
>



-- 
Lance Norskog
goksron@gmail.com

---------------------------------------------------------------------
To unsubscribe, e-mail: java-user-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-user-help@lucene.apache.org


Mime
View raw message