Bravo! On Fri, Jan 7, 2011 at 10:39 PM, Adriano Crestani <adrianocrest...@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 > <adrianocrest...@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 >> <ckstj...@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-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: java-user-h...@lucene.apache.org >>> >>> >> >
-- Lance Norskog goks...@gmail.com --------------------------------------------------------------------- To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-h...@lucene.apache.org
