[
https://issues.apache.org/jira/browse/SOLR-388?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Luke Lu updated SOLR-388:
-------------------------
Description:
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}
was:
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}
Thanks for the comments, Hoss. You explanations make sense. I can indeed work
around the issue by implementing the map interface for our data struture, which
is quite tedious as the data structure itself is not really a map. Definitely
more code than copying it to NamedList or implementing a custom writer method.
It's still less than ideal as they're serialized as <lst>...</lst> instead of
the <result>...</result> that I want, when serialized through xml.
I think the problem in the current spec is that the current DocList (which is
the only type that can write <result> elements) writer code assumes too much
implementation details (using a SolrIndexSearcher (ultimately IndexReader) to
populate a document using internal doc ids as input. If the writers can stick
to an abstract DocList interface that people can implement, then the problem is
mostly solved.
> 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 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.
-
You can reply to this email to add a comment to the issue online.
