custom query response writer

[Erik Hatcher <er...@ehatchersolutions.com>]

I'm now implementing a custom QueryResponseWriter in order to inject  
some additional information into the output.  I still am generating  
XML output, for the time being, but just with more information per  
document (it will read field information from other documents that  
are linked to the one being written, think relationships here).  I'm  
having difficulty customizing the output because XMLWriter's  
constructor is package protected.  Is there a performance or API  
reason we need this class to be uninstantiable from other packages?   
Having it still final is ok, I believe, but making the constructor  
public would help me write a custom query response writer.

Objections?

Or are there alternatives to consider to keep writing XML and  
leverage the built-in support such that SchemaField.write() provides?

Thanks,
	Erik

Re: custom query response writer

[Erik Hatcher <er...@ehatchersolutions.com>]

On Jun 15, 2006, at 10:18 AM, Yonik Seeley wrote:
> On 6/15/06, Erik Hatcher <er...@ehatchersolutions.com> wrote:
>> Having a way to hook into the response writing by leveraging the ever
>> improving Solr codebase and its utilities rather than copy/pasting
>> would be a nice way to aim, I think.
>
> It's a double edged sword.  Making more things public facilitates
> reuse, but constrains implementation and code evolution.  XMLWriter
> started out as implementation, not interface.

Those routines in XMLWriter are handy though, and are generally  
useful.  Under the covers they could still evolve.  I'm not proposing  
that we open up the internals of XMLWriter, just merely making it  
usable externally.

> For things like this, I'm OK with making it public if people are OK
> with updating their code if the class changes in the future.  It's
> seems like "expert" level usage as very few people will be writing
> their own custom response writers.

I'm not so sure about few people writing custom response writers.   
Its currently the best place to put in highlighting, and its also the  
best place for me to add in additional document data such as "more  
like this" and other related data (based on relationships to other  
documents).  And I also plan on exploring how some non-XML formats  
perform with a Ruby on Rails front-end, though in this case XMLWriter  
won't be of any use :)

> Also, there are some parts of XMLWriter (writeDate for instance) that
> we might want to move to the utils package since it would help the
> Java client.

Good point.

Personally I'm more than happy to adjust my projects code when Solr  
evolves.  I just did this the other day from my use of BitSet to  
OpenBitSet - it was not a big deal at all and very likely increased  
performance as well.  :)

	Erik

Re: custom query response writer

[Yonik Seeley <ys...@gmail.com>]

On 6/15/06, Erik Hatcher <er...@ehatchersolutions.com> wrote:
> Having a way to hook into the response writing by leveraging the ever
> improving Solr codebase and its utilities rather than copy/pasting
> would be a nice way to aim, I think.

It's a double edged sword.  Making more things public facilitates
reuse, but constrains implementation and code evolution.  XMLWriter
started out as implementation, not interface.

For things like this, I'm OK with making it public if people are OK
with updating their code if the class changes in the future.  It's
seems like "expert" level usage as very few people will be writing
their own custom response writers.

Also, there are some parts of XMLWriter (writeDate for instance) that
we might want to move to the utils package since it would help the
Java client.

-Yonik

Re: custom query response writer

[Erik Hatcher <er...@ehatchersolutions.com>]

On Jun 15, 2006, at 3:37 AM, Chris Hostetter wrote:
> : are linked to the one being written, think relationships here).  I'm
> : having difficulty customizing the output because XMLWriter's
> : constructor is package protected.  Is there a performance or API
> : reason we need this class to be uninstantiable from other packages?
> : Having it still final is ok, I believe, but making the constructor
> : public would help me write a custom query response writer.
> :
> : Objections?
>
> No objections from me ... i *think* the reason it's pacakge  
> protected at
> the moment is because the only expected use for it was to create a
> seperate instance during each invocation of the static method
> XMLWriter.writeResponse.

Which was prior to the enhancement to allow custom  
QueryResponseWriters :)

I'm fleshing out my work with my local Solr version changed to have  
it public and it is working fine for my needs.  However I did copy/ 
paste XMLResponseWriter to make my own (in a different package).   
Having a way to hook into the response writing by leveraging the ever  
improving Solr codebase and its utilities rather than copy/pasting  
would be a nice way to aim, I think.

>   (But only Yonik knows for sure what he
> anticipated).  If it stays final, i don't see any downside to  
> making the
> constructor public so other classes can reuse the write*  
> methods ... it's
> making it subclassable that would worry me a little (there may be side
> affects in some of those methods that are neccessary but non-obvious)

Yeah, agreed with the subclassing comments on XMLWriter.

	Erik

Re: custom query response writer

[Chris Hostetter <ho...@fucit.org>]

: are linked to the one being written, think relationships here).  I'm
: having difficulty customizing the output because XMLWriter's
: constructor is package protected.  Is there a performance or API
: reason we need this class to be uninstantiable from other packages?
: Having it still final is ok, I believe, but making the constructor
: public would help me write a custom query response writer.
:
: Objections?

No objections from me ... i *think* the reason it's pacakge protected at
the moment is because the only expected use for it was to create a
seperate instance during each invocation of the static method
XMLWriter.writeResponse.  (But only Yonik knows for sure what he
anticipated).  If it stays final, i don't see any downside to making the
constructor public so other classes can reuse the write* methods ... it's
making it subclassable that would worry me a little (there may be side
affects in some of those methods that are neccessary but non-obvious)



-Hoss