[
https://issues.apache.org/jira/browse/SOLR-13312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16796571#comment-16796571
]
Gus Heck commented on SOLR-13312:
---------------------------------
That interface sounds interesting. So pseudo code based on your response:
{code:java}
docInter = wrapOrConvert(luceneDoc, have_transformers)
for(transformers:t)
t.transform(docInter)
sendResponse(convertDocToWt(wt, docInter){code}
That might work if the codec/code for writing out responses only ever iterates
linearly through the document anyway... which seems likely for writing a
response. If the interface provides direct field access, the performance of
field access would vary depending on the impl behind it, one favoring memory at
the expense of cpu the other favoring cpu at the expense of memory (for cases
expecting lots of direct field access). Certain use cases (low mem systems)
might want to force the tradeoff regardless.
One might even imagine a composition based strategy with an
.optimizeFieldAccess() method that flips the map based backing implementation
on by swapping in a SolrDocument as a new delegate on demand, so that
transformers that do nothing but add one more field don't have to require the
more memory expensive implementation either.
Maybe convert the current SolrDocument class to an inner class of a wrapper
that takes it's name, and that wrapper that can delegate either to a lucene doc
or the current impl. Then have an optimizeForFiledAccess() method that code in
transfomrers (or elsewhere) can call to hint that a map based backing may be
helpful for performance (I imagine perhaps allowing a sysprop or config setting
to deny this request for memory constrained systems or systems handling
documents with very few fields). A new constructor would create the lucene
backed version, and the existing constructors create one backed by maps as
before...
Certain methods such as "getFieldValuesAsMap()" might automatically cause
conversion...
Just a thought.
> write out responses without creating SolrDocument objects
> ---------------------------------------------------------
>
> Key: SOLR-13312
> URL: https://issues.apache.org/jira/browse/SOLR-13312
> Project: Solr
> Issue Type: Sub-task
> Security Level: Public(Default Security Level. Issues are Public)
> Reporter: Noble Paul
> Priority: Major
>
> Once we get a document from lucene there is no need to create a SolrDocument
> object to write out the response, if there are no transformers
--
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
