Mailing-List: contact solr-dev-help@lucene.apache.org; run by ezmlm
Precedence: bulk
Reply-To: solr-dev@lucene.apache.org
Message-ID: <1095573310.1258470100559.JavaMail.jira@brutus>
Date: Tue, 17 Nov 2009 15:01:40 +0000 (UTC)
From: "Chris A. Mattmann (JIRA)" <jira@apache.org>
To: solr-dev@lucene.apache.org
Subject: [jira] Issue Comment Edited: (SOLR-1516) DocumentList and Document
 QueryResponseWriter
In-Reply-To: <1904121855.1255917271326.JavaMail.jira@brutus>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/SOLR-1516?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12778919#action_12778919 ] 

Chris A. Mattmann edited comment on SOLR-1516 at 11/17/09 3:01 PM:
-------------------------------------------------------------------

bq. Most of the custom writers are less bothered about sections other than the DocList. The hard part is in reading the stored fields from lucene Documents depending on what fields are requested by the user. If the API allows to fetch the data as an Iterator<SolrDocument> w/o bothering about the low level Lucene details that would be ideal.

This is exactly my point with this issue. I think that you and I are on the same page, Noble. I took a look at the patch you uploaded:

{code}
  public abstract void start(Writer writer);

  /**Start of document list
   * @param info
   */
  public abstract void startDocumentList(Writer writer, DocListInfo info);
  /**Write out a document
   * @param solrDocument
   */
  public abstract void writeDoc(Writer writer,SolrDocument solrDocument);

  /**End of documents
   */
  public abstract void endDocumentList(Writer writer,);

  /**write the header if required
   * @param responseHeader
   */
  public abstract void writeResponseHeader(Writer writer,NamedList responseHeader);

  public abstract void end(Writer writer);
{code}

1. You include a #writeDoc function. In my patch I called this #emitDoc. Why the name change?
2. Same goes for #startDocumentList and #endDocumentList (called #emitHeader and #emitFooter in my patch). Why the name change?
3. #start and #end are never called in your patch?
4. The javadoc I included in my patch is not included in yours.
5. My patch included a means to get the whole DocumentList (in the case that aggregate formatting is required) -- this is removed in your patch. Your patch includes only the equivalent of my DocumentResponseWriter.
6. The spirit of your patch is a bit more generic than mine, e.g., with the writeOther method. +1 to that.

Let me take a crack at merging what you put up and what I wrote. Sound good?

      was (Author: chrismattmann):
    bq. Most of the custom writers are less bothered about sections other than the DocList. The hard part is in reading the stored fields from lucene Documents depending on what fields are requested by the user. If the API allows to fetch the data as an Iterator<SolrDocument> w/o bothering about the low level Lucene details that would be ideal.

This is exactly my point with this issue. I think that you and I are on the same page, Noble. I took a look at the patch you uploaded:

{format}
  public abstract void start(Writer writer);

  /**Start of document list
   * @param info
   */
  public abstract void startDocumentList(Writer writer, DocListInfo info);
  /**Write out a document
   * @param solrDocument
   */
  public abstract void writeDoc(Writer writer,SolrDocument solrDocument);

  /**End of documents
   */
  public abstract void endDocumentList(Writer writer,);

  /**write the header if required
   * @param responseHeader
   */
  public abstract void writeResponseHeader(Writer writer,NamedList responseHeader);

  public abstract void end(Writer writer);
{format}

1. You include a #writeDoc function. In my patch I called this #emitDoc. Why the name change?
2. Same goes for #startDocumentList and #endDocumentList (called #emitHeader and #emitFooter in my patch). Why the name change?
3. #start and #end are never called in your patch?
4. The javadoc I included in my patch is not included in yours.
5. My patch included a means to get the whole DocumentList (in the case that aggregate formatting is required) -- this is removed in your patch. Your patch includes only the equivalent of my DocumentResponseWriter.
6. The spirit of your patch is a bit more generic than mine, e.g., with the writeOther method. +1 to that.

Let me take a crack at merging what you put up and what I wrote. Sound good?
  
> DocumentList and Document QueryResponseWriter
> ---------------------------------------------
>
>                 Key: SOLR-1516
>                 URL: https://issues.apache.org/jira/browse/SOLR-1516
>             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, SOLR-1516.patch
>
>
> 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.