[
https://issues.apache.org/jira/browse/SOLR-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536482
]
Hoss Man commented on SOLR-388:
-------------------------------
As a general rule, we've worked hard to ensure Solr will never have the problem
of "RequestHandlerX can't be used with ResponseWriterY because X puts objects
of type Z in the response" ... that's why we have the SolrQueryResponse
contract...
http://lucene.apache.org/solr/api/org/apache/solr/request/SolrQueryResponse.html#returnable_data
...even if we used double dispatching, this potential for incompatibility would
still exist.
The list of "returnable data" in the SolrQueryResponse contract was designed to
simple enough that any output format should be able to support all of the types
on the list, while still being broad enough that any complex object could be
expressed as combinations of the "primitive" types on the list.
Luke: I suggest you start a thread on solr-user discussing your specific goal,
so we can see if people have ideas on how to get your request handler returning
the data you want in a format that any response writer can output.
That said: there's not much harm in cleaning up the the ResponseWriters so they
could be subclassed by people who want enough rope to hang themselves, but i
don't think we should be encouraging ResponseWriters that aren't reusable by
going with the double dispatch approach.
> Refactor ResponseWriters and Friends.
> -------------------------------------
>
> Key: SOLR-388
> URL: https://issues.apache.org/jira/browse/SOLR-388
> Project: Solr
> Issue Type: Improvement
> Components: search
> Affects Versions: 1.2
> Reporter: Luke Lu
>
> When developing custom request handlers, it's often necessary to create
> corresponding response writers that extends existing ones. In our case, we
> want to augment the result list (more attributes other than numFound,
> maxScore, on the fly per doc attributes that are not fields etc.) , only to
> find JSONWriter and friends are private to the package. We could copy the
> whole thing and modify it, but it wouldn't take advantage of recent fixes
> like Yonik's FastWriter changes without tedious manual intervention. I hope
> that we can can *at least* extends it and overrides writeVal() to add a new
> result type to call writeMyType.
> Ideally the ResponseWriter hierarchy could be rewritten to take advantage of
> a double dispatching trick to get rid of the ugly if something is instance of
> someclass else ... list, as it clearly doesn't scale well with number of
> types (_n_) and depth (_d_) of the writer hierarchy, as the complexity would
> be O(_nd_), which worse than the O(1) double dispatching mechanism. Some
> pseudo code here:
> {code:title=SomeResponseWriter.java}
> // a list of overloaded write method
> public void write(SomeType t) {
> // implementation
> }
> {code}
> {code:title=ResponseWritable.java}
> // an interface for objects that support the scheme
> public interface ResponseWritable {
> public abstract void write(ResponseWriter writer);
> }
> {code}
> {code:title=SomeType.java}
> // Sometype needs to implement the ResponseWritable interface
> // to facilitate double dispatching
> public void write(ResponseWriter writer) {
> writer.write(this);
> }
> {code}
> So when adding a new MyType and MySomeResponseWriter, we only need to add
> these two files without having to muck with the writeVal if-then-else list.
> Note, you still need to use the if else list for builtin types and any types
> that you can't modify in the write(Object) method.
> {code:title=MyType.java}
> // implements the ResponseWritable interface
> public write(ResponseWriter writer) {
> writer.write(this);
> }
> {code}
> {code:title=MySomeResponseWriter.java}
> // only need to implement this method
> public void write(MyType t) {
> // implementation
> }
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
