[
https://issues.apache.org/jira/browse/SOLR-12625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16575035#comment-16575035
]
Erick Erickson commented on SOLR-12625:
---------------------------------------
{quote}Per chance TestChildDocTransformer?
{quote}
Yeah, and the latest iteration has fails in three Transformers....
{quote}It'd be nice if SolrReturnFields didn't itself have to reference
{quote}
Putting it in SolrReturnFields was super-ugly, either a bidirectional reference
which I dislike too or I would have had to pass 4 different lists , neither of
which I could stand. Having just a set/get for the optimizer isn't great
either, but it's better.
{quote}First, why just Strings when the type might be something else like a
Date?
{quote}
What does the calling code look like then? I have this SolrDocument and I want
to get "field1". Do I have code like
{code:java}
if (val instanceof String) {
String eoeS = (String)val;
} else if (val instanceof Date) {
Date eoeD = (Date)val;
} etc?
{code}
That's its own kind of ugly.
or
{code:java}
if (fieldType instanceof IntValueFieldType) {
if (multiValued) {
writers[i] = new MultiFieldWriter(field, fieldType, schemaField,
true);
} else {
writers[i] = new IntFieldWriter(field);
}
} else if (fieldType instanceof LongValueFieldType) {
if (multiValued) {
writers[i] = new MultiFieldWriter(field, fieldType, schemaField,
true);
} else {
writers[i] = new LongFieldWriter(field);
}
} else if (fieldType instanceof FloatValueFieldType) {
etc....
{code}
That said, it's another kind of ugly to have code that parses the string that's
been automagically converted.
WDYT about
1> making the code convert to native types and have a getValAsString() method
that at least conceals the above ugliness when the user doesn't care?
2> forgetting the boolean for SolrDocumentFetcher.solrDoc, just convert to
native types regardless. I don't really see a good purpose to be served by
allowing the option here. The goal is to make it simpler to use so one less
option seems good.
> Combine SolrDocumentFetcher and RetrieveFieldsOptimizer
> -------------------------------------------------------
>
> Key: SOLR-12625
> URL: https://issues.apache.org/jira/browse/SOLR-12625
> Project: Solr
> Issue Type: Improvement
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Erick Erickson
> Assignee: Erick Erickson
> Priority: Major
> Attachments: SOLR-12625.patch, SOLR-12625.patch
>
>
> We have SolrDocumentFetcher and RetrieveFieldsOptimizer. The
> relationship between the two is unclear at first glance. Using
> SolrDocumentFetcher by itself is (or can be) inefficient.
> WDYT about combining the two? Is there a good reason you would want to
> use SolrDocumentFetcher _instead_ of RetrieveFieldsOptimizer?
> Ideally I'd want to be able to write code like:
> solrDocumentFetcher.fillDocValuesMostEfficiently
> That created an optimizer and "did the right thing".
> Assigning to myself to keep track, but if anyone feels motivated feel free to
> take it over.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
