On Mon, Nov 24, 2008 at 7:25 AM, Chris Hostetter <[EMAIL PROTECTED]> wrote: > > : > Logging an error and returning successfully (without adding any docs) is > : > still inconsistent with the way all other RequestHandlers work: fail the > : > request. > : > > : > I know DIH isn't a typical RequestHandler, but some things (like failing > : > on failure) seem like they should be a given. > : SOLR-842 . > : DIH is an ETL tool pretending to be a RequestHandler. Originally it > : was built to run outside of Solr using SolrJ. For better integration > : and ease of use we changed it later. > : > : SOLR-853 aims to achieve the oroginal goal > : > : The goal of DIH is to become a full featured ETL tool. > > Understood ... but shouldn't ETL Tools "fail on failure" ? > > I mean forget Solr for a minute: If i've got a standalone ETL Tool that > runs as a daemon, and on startup it logs some error messages because i've > got bad configs (and it can tell the fields i've listed for my > 'target' system don't exist there) should it report "success" everytime i > push data to it? > > Based on this thread, that's what it sounds like DIH is doing right now in > situations like this. > > If nothing else, we could give DIH a way to check the global > <abortOnConfigurationError> value from solrconfig.xml and make it's > decisison that way We considered these. The severity of errors are very much specific to the source of data. It is very unlikely that a DB source throws up errors. In xml data sources say out of x urls 1 or two are wrong, would the user wish to ignore or want to abort the entire import.
So we decided to give more options and the implementations are left to the EntityProcessor. Moreover the default is set to onError=abort > > > > -Hoss > > -- --Noble Paul
