[jira] Issue Comment Edited: (SOLR-388) Refactor ResponseWriters and Friends.

["Luke Lu (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SOLR-388?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12536487 ] 

vicaya edited comment on SOLR-388 at 10/22/07 7:20 PM:
--------------------------------------------------------

Thanks for the pointers, Hoss. I can certainly copy/convert the results into a NamedList composed only of the primitives. But it's an extra copy that's bad for the performance, especially when the result list is relatively large, as in my case it's not an extra field per response, but a few things per document. BTW, the documentation needs to be updated to reflect that Document is also a supported primitive.

I've searched the mailing list for JSONWriter. There are at least two threads asking for it to be public like XMLWriter. But no bugs have been filed and JSONWriter is still a class private to the package as of today in solr trunk, hence this bug. The double dispatching proposal is just an idea to make the code a bit cleaner and more efficient, as well as enable efficient reuse outside the solr release.

I'd be happy if the only outcome of this issue is to have JSONWriter refactored into a public class that people can subclass.

      was (Author: vicaya):
    Thanks for the pointers, Hoss. I can certainly copy/convert the results into a NamedList composed only of the primitives. But it's an extra copy that's bad for the performance, especially when the result list is relatively large, as in my case it's not an extra field per response, but a few things per document. BTW, the documentation needs to be updated to reflect that Document is also a supported primitive.

I've searched the mailing list for JSONWriter. There are at least two threads asking for it to be public like XMLWriter. But no bugs have been filed and JSONWriter is still a class private to the package as of today in solr trunk, hence this bug. The double dispatching proposal is just an idea to make the code a bit cleaner and more efficient, as well as enable efficient reuse outside the solr release.

I'd happy if the only outcome of this issue is to have JSONWriter refactored into a public class that people can subclass.
  
> 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.