lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Ryan McKinley (JIRA)" <j...@apache.org>
Subject [jira] [Resolved] (SOLR-388) Refactor ResponseWriters and Friends.
Date Wed, 08 Jun 2011 19:17:58 GMT

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

Ryan McKinley resolved SOLR-388.
--------------------------------

       Resolution: Duplicate
    Fix Version/s: 4.0

the types of thigns this issue points to are taken care of in SOLR-1566

> Refactor ResponseWriters and Friends.
> -------------------------------------
>
>                 Key: SOLR-388
>                 URL: https://issues.apache.org/jira/browse/SOLR-388
>             Project: Solr
>          Issue Type: Improvement
>          Components: Response Writers
>    Affects Versions: 1.2
>            Reporter: Luke Lu
>             Fix For: 4.0
>
>
> When developing custom request handlers, it's often necessary to create corresponding
response writers that extend 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message