Return-Path: X-Original-To: apmail-lucene-dev-archive@www.apache.org Delivered-To: apmail-lucene-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 4EF149E72 for ; Tue, 25 Oct 2011 12:42:20 +0000 (UTC) Received: (qmail 38679 invoked by uid 500); 25 Oct 2011 12:42:19 -0000 Delivered-To: apmail-lucene-dev-archive@lucene.apache.org Received: (qmail 38614 invoked by uid 500); 25 Oct 2011 12:42:19 -0000 Mailing-List: contact dev-help@lucene.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@lucene.apache.org Delivered-To: mailing list dev@lucene.apache.org Received: (qmail 38607 invoked by uid 99); 25 Oct 2011 12:42:19 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 25 Oct 2011 12:42:19 +0000 X-ASF-Spam-Status: No, hits=1.5 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of joshua.k.harness@gmail.com designates 209.85.220.176 as permitted sender) Received: from [209.85.220.176] (HELO mail-vx0-f176.google.com) (209.85.220.176) by apache.org (qpsmtpd/0.29) with ESMTP; Tue, 25 Oct 2011 12:42:12 +0000 Received: by vcdn13 with SMTP id n13so475826vcd.35 for ; Tue, 25 Oct 2011 05:41:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type; bh=1B8SfktASBju47DKFc/Il30yFDQquRnL4G157B+QpoY=; b=TpzDqWQwr1zJKXLHN1MNtPEMFIKdcKAMBhAmv5HH1YtWRkBrSC/AZuZ2G3nat2vgEO KePtAaRfgJ1jSABFg548o79r6CXmQ7OMgjLdKUG21qSJULth05ehEcJKdcbFSRcYAPAc n+3ok5nv6eT6Ty24KFp1G/r4IZLZsCVZZI7vw= MIME-Version: 1.0 Received: by 10.182.51.103 with SMTP id j7mr4266054obo.36.1319546511103; Tue, 25 Oct 2011 05:41:51 -0700 (PDT) Sender: joshua.k.harness@gmail.com Received: by 10.182.15.169 with HTTP; Tue, 25 Oct 2011 05:41:51 -0700 (PDT) In-Reply-To: References: Date: Tue, 25 Oct 2011 08:41:51 -0400 X-Google-Sender-Auth: oYe6dgc9fqSPqjwCY2hvvZIpfEY Message-ID: Subject: Re: Request for Feedback for Patch to Allow DIH to Archive Files From: Josh Harness To: dev@lucene.apache.org Content-Type: multipart/alternative; boundary=f46d044517830f18ad04b01edd8f X-Virus-Checked: Checked by ClamAV on apache.org --f46d044517830f18ad04b01edd8f Content-Type: text/plain; charset=ISO-8859-1 Martijn, Thanks for the feedback. I have created SOLR-2851for this feature request. Please let me know if there's anything else you'd like me to do. Thanks! Josh On Tue, Oct 25, 2011 at 2:29 AM, Martijn v Groningen < martijn.v.groningen@gmail.com> wrote: > Hi Josh, > > I think this functionality is useful. I'd create an Jira issue and > attach your code as a patch. I think that the functionality should be > added to the FileListEntityProcessor since it seems to be a more > natural place for it. Maybe we need something more generic, like a > post action if a file has been processed. > > Martijn > > On 24 October 2011 21:31, Josh Harness wrote: > > Hi - > > > > We are using SOLR to process XML input files using the Data Import > > Handler. I didn't see a way to move the xml files out of the way after > > processing, so I wrote a small extension to allow this. The "How to > > Contribute" page says to pitch the request to the developer list in order > to > > decide whether or not to submit a patch. As such, here goes: > > > > The new code basically extends FileDataSource and wraps the > underlying > > reader such that when the "close" method on the input stream is called, > the > > file is moved to a configurable archive directory. It is unclear to me > > whether this is the correct place to put it (I pondered changing the > > FileListEntityProcessor but this somehow felt safer). I realize that a > more > > robust implementation would consider the success status of the file being > > processed and would also allow for configurable policies rather than a > > concrete implementation. Nonetheless, I didn't want the perfect to be the > > enemy of the good. > > > > Please peruse the attached source code file and provide feedback as > to > > the merit of the idea, whether I ought to submit a JIRA ticket/patch and > if > > my approach is correct. > > > > Thanks! > > > > Josh Harness > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org > > For additional commands, e-mail: dev-help@lucene.apache.org > > > > > > -- > Met vriendelijke groet, > > Martijn van Groningen > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org > For additional commands, e-mail: dev-help@lucene.apache.org > > --f46d044517830f18ad04b01edd8f Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Martijn,

=A0=A0=A0=A0 Thanks for the feedback. I have created SOLR-2851 for thi= s feature request. Please let me know if there's anything else you'= d like me to do.

Thanks!

Josh

On Tue, Oct 25, 2= 011 at 2:29 AM, Martijn v Groningen <martijn.v.groningen@gmail.com> wrote:
Hi Josh,

I think this functionality is useful. I'd create an Jira issue and
attach your code as a patch. I think that the functionality should be
added to the FileListEntityProcessor since it seems to be a more
natural place for it. Maybe we need something more generic, like a
post action if a file has been processed.

Martijn

On 24 October 2011 21:31, Josh Harness <josh.harness@jtv.com> wrote:
> Hi -
>
> =A0=A0=A0=A0 We are using SOLR to process XML input files using the Da= ta Import
> Handler. I didn't see a way to move the xml files out of the way a= fter
> processing, so I wrote a small extension to allow this. The "How = to
> Contribute" page says to pitch the request to the developer list = in order to
> decide whether or not to submit a patch. As such, here goes:
>
> =A0=A0=A0=A0 The new code basically extends FileDataSource and wraps t= he underlying
> reader such that when the "close" method on the input stream= is called, the
> file is moved to a configurable archive directory. It is unclear to me=
> whether this is the correct place to put it (I pondered changing the > FileListEntityProcessor but this somehow felt safer). I realize that a= more
> robust implementation would consider the success status of the file be= ing
> processed and would also allow for configurable policies rather than a=
> concrete implementation. Nonetheless, I didn't want the perfect to= be the
> enemy of the good.
>
> =A0=A0=A0=A0 Please peruse the attached source code file and provide f= eedback as to
> the merit of the idea, whether I ought to submit a JIRA ticket/patch a= nd if
> my approach is correct.
>
> Thanks!
>
> Josh Harness
>
>
> ----------------------------------------------------------= -----------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
>



--
Met vriendelijke groet,

Martijn van Groningen

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


--f46d044517830f18ad04b01edd8f--