lucene-solr-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Noble Paul (JIRA)" <>
Subject [jira] Commented: (SOLR-1516) DocumentList and Document QueryResponseWriter
Date Tue, 17 Nov 2009 04:05:39 GMT


Noble Paul commented on SOLR-1516:

bq. Can you elaborate on why you don't think this patch adds value? I've elaborated above
on the value I think that this brings, and I would appreciate the same level of detail regarding
the contrary.

This does not help the user of the API much because the real difficulty is in unmarshalling
various types of objects. This patch does nothing to read the stored fields from the Document

bq. I'm also for getting rid of the abstract data structure (bag of objects) class called
NamedValueList and replacing it with a more concrete type hierarchy....

That is really difficult. A lot of components write their output in a very arbitrary Object
tree. The output is largely designed like a JSON object tree (with more promitives) . The
producer decides what the tree contains. The good thing about this approach is that we don't
need to build custom classes  for every type of output.

bq. On the other hand, my patch is focused on allowing the user to hijack simply the returned

There is no reason why a GenericResponseWriter can't do that . I am not happy about putting
this classes in and leading users to believe that this is all that they have to do.

> DocumentList and Document QueryResponseWriter
> ---------------------------------------------
>                 Key: SOLR-1516
>                 URL:
>             Project: Solr
>          Issue Type: New Feature
>          Components: search
>    Affects Versions: 1.3
>         Environment: My MacBook Pro laptop.
>            Reporter: Chris A. Mattmann
>            Assignee: Noble Paul
>            Priority: Minor
>             Fix For: 1.5
>         Attachments: SOLR-1516.Mattmann.101809.patch.txt
> I tried to implement a custom QueryResponseWriter the other day and was amazed at the
level of unmarshalling and weeding through objects that was necessary just to format the output
o.a.l.Document list. As a user, I wanted to be able to implement either 2 functions:
> * process a document at a time, and format it (for speed/efficiency)
> * process all the documents at once, and format them (in case an aggregate calculation
is necessary for outputting)
> So, I've decided to contribute 2 simple classes that I think are sufficiently generic
and reusable. The first is o.a.s.request.DocumentResponseWriter -- it handles the first bullet
above. The second is o.a.s.request.DocumentListResponseWriter. Both are abstract base classes
and require the user to implement either an #emitDoc function (in the case of bullet 1), or
an #emitDocList function (in the case of bullet 2). Both classes provide an #emitHeader and
#emitFooter function set that handles formatting and output before the Document list is processed.

This message is automatically generated by JIRA.
You can reply to this email to add a comment to the issue online.

View raw message