Return-Path: Delivered-To: apmail-lucene-solr-dev-archive@minotaur.apache.org Received: (qmail 75399 invoked from network); 11 Jun 2009 08:51:21 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 11 Jun 2009 08:51:21 -0000 Received: (qmail 81334 invoked by uid 500); 11 Jun 2009 08:51:32 -0000 Delivered-To: apmail-lucene-solr-dev-archive@lucene.apache.org Received: (qmail 81279 invoked by uid 500); 11 Jun 2009 08:51:31 -0000 Mailing-List: contact solr-dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: solr-dev@lucene.apache.org Delivered-To: mailing list solr-dev@lucene.apache.org Received: (qmail 81269 invoked by uid 99); 11 Jun 2009 08:51:31 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 11 Jun 2009 08:51:31 +0000 X-ASF-Spam-Status: No, hits=-2000.0 required=10.0 tests=ALL_TRUSTED X-Spam-Check-By: apache.org Received: from [140.211.11.140] (HELO brutus.apache.org) (140.211.11.140) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 11 Jun 2009 08:51:28 +0000 Received: from brutus (localhost [127.0.0.1]) by brutus.apache.org (Postfix) with ESMTP id C2C04234C046 for ; Thu, 11 Jun 2009 01:51:07 -0700 (PDT) Message-ID: <1181611795.1244710267796.JavaMail.jira@brutus> Date: Thu, 11 Jun 2009 01:51:07 -0700 (PDT) From: "Noble Paul (JIRA)" To: solr-dev@lucene.apache.org Subject: [jira] Updated: (SOLR-1120) Simplify EntityProcessor API In-Reply-To: <1230918395.1239952754912.JavaMail.jira@brutus> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-JIRA-FingerPrint: 30527f35849b9dde25b450d4833f0394 X-Virus-Checked: Checked by ClamAV on apache.org [ https://issues.apache.org/jira/browse/SOLR-1120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-1120: ----------------------------- Attachment: SOLR-1120.patch a new method added to EntityProcessor (postTransform) . this can be used by the EntityProcessor implementations to get a callback after the transformations are done > Simplify EntityProcessor API > ---------------------------- > > Key: SOLR-1120 > URL: https://issues.apache.org/jira/browse/SOLR-1120 > Project: Solr > Issue Type: Improvement > Components: contrib - DataImportHandler > Affects Versions: 1.3 > Reporter: Shalin Shekhar Mangar > Assignee: Shalin Shekhar Mangar > Fix For: 1.4 > > Attachments: SOLR-1120.patch, SOLR-1120.patch, SOLR-1120.patch, SOLR-1120.patch, SOLR-1120.patch, SOLR-1120.patch, SOLR-1120.patch, SOLR-1120.patch, SOLR-1120.patch > > > Writing an EntityProcessor is deceptively complex. There are so many gotchas. > I propose the following: > # Extract out the Transformer application logic from EntityProcessor and add it to DocBuilder. Then EntityProcessor do not need to call applyTransformer or know about rowIterator and getFromRowCache() methods. > # Change the meaning of EntityProcessor#destroy to be called on end of parent's row -- Right now init is called once per parent row but destroy actually means the end of import. In fact, there is no correct way for an entity processor to do clean up right now. Most do clean up when returning null (end of data) but with the introduction of $skipDoc, a transformer can return $skipDoc and the entity processor will never get a chance to clean up for the current init. > # EntityProcessor will use the EventListener API to listen for import end. This should be used by EntityProcessor to do a final cleanup. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.