Hi Yonik,
I was about to create the issue in JIRA and for that I copied the output
to a text editor (JEdit, in fact). But JEdit displays valid XML which I
am not able to paste into here (Thunderbird). I think Thunderbird is not
using UTF-8, even if it asks whether it should send UTF-8.
This means the XML is probably valid when parsed using Java (i.e. using
SolrJ).
So, shall I still open an issue about externalization? That would be a
change request that is not backward compatible if it's changing the
output of existing queries? So, maybe this would require an additional
parameter that flags whether those values shall be externalized or not?
I had a quick look at the source code of MoreLikeThisHelper and it
delegates the creation of the String to a lucene class:
if( interesting != null ) {
if( termStyle == TermStyle.DETAILS ) {
NamedList<Float> it = new NamedList<Float>();
for( InterestingTerm t : interesting ) {
it.add( t.term.toString(), t.boost );
}
rsp.add( "interestingTerms", it );
}
else {
List<String> it = new ArrayList<String>( interesting.size() );
for( InterestingTerm t : interesting ) {
it.add( t.term.text());
}
rsp.add( "interestingTerms", it );
}
}
term is of type org.apache.lucene.Term.
toString() and text() both return the non-externalized values.
I'll ask on solr-user how to get the actual int value when provided with
the internal value of a SortableIntField. I had no luck with converting
this, so far.
Cheers,
Chantal
Yonik Seeley schrieb:
On Tue, Nov 10, 2009 at 8:54 AM, Chantal Ackermann
<chantal.ackerm...@btelligent.de> wrote:
Hi Yonik,
I'll do that. Is this a general requirement: that the terms have to be
externalized? Because the TermVectorComponent doesn't externalize either.
Shall the ticket mention that?
It generally seems like a good idea...
I'm not sure what the right answer is for TermVectorComponent (it sort
of depends on how one expects to use it), but you can go ahead and
open a bug to track it.
-Yonik
http://www.lucidimagination.com
